2017-06-16 5 views
0

Ich habe versucht, den simplify CFG Pass in LLVM laufen und einen unerreichbaren Basisblock löschen, nachdem meinen eigenen von laufenden IR verwandelt, aber ich halte den Fehler bekommen -simplifyCFG passiert in llvm

beim Löschen: i8 *% g

Gebrauch immer noch um steckt nach Def zerstört: store i8 0, i8 *% g

ich bin mir sehr wohl bewusst, was das bedeutet, aber nicht der ganze Zweck der "simplifyCFGPass" zum Löschen des nicht erreichbaren Bas ic Blöcke für uns? Warum muss es dann diesen Fehler werfen? Ich würde annehmen, dass es einfach in der Lage sein sollte, alle Nutzungs-Def-Abhängigkeiten zu verwalten und die Anweisungen in dem unerreichbaren Basisblock "continuation" unten zu löschen.

Es folgt der entsprechenden IR -

entry: 
    %a3 = alloca i32 
    store i32 %a, i32* %a3 
    %a4 = load i32, i32* %a3 
    %ifcond = icmp ne i32 %a4, 0 
    br i1 %ifcond, label %then, label %else 



then:            ; preds = %entry 
    %gclone1 = alloca i32 
    store i32 0, i32* %gclone1 
    ret i5 0 

else:            ; preds = %entry 
    %gclone4 = alloca i64 
    store i64 0, i64* %gclone4 
    ret i5 0 

continuation:          ; No predecessors! 
    %iftmp = phi i32 [ 32, %then ], [ 64, %else ], !range !0 
    %datasize = alloca i32 
    store i32 %iftmp, i32* %datasize 

    %g = alloca i8 ---------------------> Issue 
    store i8 0, i8* %g ---------------------> Issue 
    ret i5 0 
} 

Kann jemand bitte erklären, warum dieser Fehler auftaucht? Soll die API das nicht handhaben?

+0

Tritt dieser Fehler auf, wenn Sie Ihre Umwandlung ausführen oder wenn Sie simplifyCFGPass ausführen? – deLta

+0

Ich führe den CFG Pass (mit FPM-> run (* F)) ... mein Pass ist einfach einige C++ - Code, der die IR ändert, ich benutze es nicht in der Opt-Tool oder so etwas ... – mal

Antwort

0

Ihre IR ist deutlich beschädigt. Sie sind mit:

% iftmp = phi i32 [32% dann], [64% else], Bereich 0

jedoch pro LLVM IR-Spezifikation (http://llvm.org/docs/LangRef.html#phi-instruction)!:

Der Typ der eingehenden Werte wird mit dem ersten Feld angegeben. Danach nimmt die 'phi' Anweisung eine Liste von Paaren als Argumente, mit einem Paar für jeden Vorgänger-Basisblock des aktuellen Blocks. Nur Werte des ersten Klassentyps können als Wertargumente für den PHI-Knoten verwendet werden. Nur Etiketten können als das Etikett Argumente verwendet werden.

Dies ist in Ihrem Fall eindeutig verletzt und daher können die nachfolgenden IR-Umwandlungsdurchläufe leicht fehlschlagen. Ich würde vorschlagen, dass Sie den IR-Verifikations-Pass (z. B. via opt -verify) nach dem Transformations-Durchlauf ausführen.

+0

Nein. Ich denke, ich habe in der Frage "Löschen eines unerreichbaren Basisblocks nach dem Ausführen einer meiner eigenen IR-Transformationen" klar erwähnt. Der Phi-Knoten ist nicht unterbrochen (und der Verifier-Durchgang erkennt kein Problem) – mal

+0

Der Phi-Knoten ist sicher defekt. Weder% else noch% sind dann Vorgänger von% continuation –