FileCheck-3.6 - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

FileCheck - Flexibler Dateiverifizierer für den Mustervergleich

ZUSAMMENFASSUNG

Dateiprüfung Match-Dateiname [--check-prefix=XXX] [--strict-whitespace]

BESCHREIBUNG

Dateiprüfung liest zwei Dateien (eine von der Standardeingabe und eine in der Befehlszeile angegeben)
und verwendet einen, um den anderen zu überprüfen. Dieses Verhalten ist besonders nützlich für die Testsuite,
die überprüfen möchte, ob die Ausgabe eines Tools (z Llc) enthält das erwartete
Informationen (zum Beispiel ein movsd von esp oder was auch immer interessant ist). Das ist ähnlich
zur Verwendung von grep, aber es ist optimiert, um mehrere verschiedene Eingaben in einer Datei in a . abzugleichen
bestimmten Auftrag.

Das Match-Dateiname file gibt die Datei an, die die zu vergleichenden Muster enthält. Die Datei
zu überprüfen wird von der Standardeingabe gelesen, es sei denn, die --Eingabedatei Option verwendet wird.

OPTIONAL

-Hilfe Drucken Sie eine Zusammenfassung der Befehlszeilenoptionen.

--check-präfix Präfix
FileCheck durchsucht den Inhalt von Match-Dateiname damit Muster übereinstimmen. Von
Standardmäßig haben diese Muster das Präfix "PRÜFEN:". Wenn Sie a . verwenden möchten
unterschiedliches Präfix (z. B. weil dieselbe Eingabedatei mehrere unterschiedliche überprüft)
Werkzeug oder Optionen), die --check-präfix Argument ermöglicht die Angabe eines oder mehrerer
Präfixe übereinstimmen. Mehrere Präfixe sind nützlich für Tests, die sich ändern können
verschiedene Ausführungsoptionen, aber die meisten Linien bleiben gleich.

--Eingabedatei Dateinamen
Zu überprüfende Datei (standardmäßig stdin).

--strict-whitespace
Standardmäßig kanonisiert FileCheck eingegebene horizontale Leerzeichen (Leerzeichen und Tabulatoren).
was dazu führt, dass diese Unterschiede ignoriert werden (ein Leerzeichen entspricht einer Registerkarte). Die
--strict-whitespace Argument deaktiviert dieses Verhalten. Zeilenende-Sequenzen sind
kanonisiert auf UNIX-Stil \n in allen Modi.

--implizit-check-not Kontrollmuster
Fügt implizite negative Prüfungen für die angegebenen Muster zwischen positiven Prüfungen hinzu.
Die Option ermöglicht das Schreiben strengerer Tests, ohne sie mit zu füllen CHECK-NOTs.

Zum Beispiel, "--implizit-check-not Warnung:" kann beim Testen der Diagnose nützlich sein
Nachrichten von Tools, die keine ähnliche Option wie . haben Klappern -verifizieren. Mit diesem
Option FileCheck überprüft, ob die Eingabe keine Warnungen enthält, die nicht von abgedeckt sind
jedem PRÜFEN: Muster.

-Ausführung
Zeigen Sie die Versionsnummer dieses Programms an.

EXIT STATUS

If Dateiprüfung überprüft, ob die Datei dem erwarteten Inhalt entspricht, wird sie mit 0 beendet.
Andernfalls, wenn nicht oder ein Fehler auftritt, wird es mit einem Wert ungleich Null beendet.

TUTORIAL

FileCheck wird normalerweise von LLVM-Regressionstests verwendet und in der RUN-Zeile von . aufgerufen
der Test. Ein einfaches Beispiel für die Verwendung von FileCheck aus einer RUN-Zeile sieht so aus:

; AUSFÜHREN: llvm-as < %s | llc -march=x86-64 | DateiCheck %s

Diese Syntax besagt, dass die aktuelle Datei ("%s") in llvm-wie, rohr das in Llc und dann
Pipe die Ausgabe von Llc in Dateiprüfung. Das bedeutet, dass FileCheck seine
Standardeingabe (die llc-Ausgabe) gegen das angegebene Dateinamenargument (das Original) .NS
Datei angegeben durch "%s"). Um zu sehen, wie das funktioniert, schauen wir uns den Rest an .NS Datei
(nach der RUN-Zeile):

definiere void @sub1(i32* %p, i32 %v) {
Eintrag:
; PRÜFEN: sub1:
; PRÜFEN: subl
%0 = Rückruf i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
ret nichtig
}

definiere void @inc4(i64* %p) {
Eintrag:
; PRÜFEN: inc4:
; PRÜFEN: Incq
%0 = Rückruf i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
ret nichtig
}

Hier sehen Sie einige "PRÜFEN:" Zeilen in Kommentaren angegeben. Jetzt können Sie sehen, wie die Datei
wird eingespeist llvm-wie und dann Llc, und die Maschinencodeausgabe ist das, was wir überprüfen.
FileCheck überprüft die Maschinencodeausgabe, um sicherzustellen, dass sie mit dem übereinstimmt, was "PRÜFEN:" Linien
angeben.

Die Syntax des "PRÜFEN:"Zeilen ist sehr einfach: Sie sind feste Zeichenfolgen, die in vorkommen müssen
Auftrag. FileCheck ignoriert standardmäßig horizontale Leerraumunterschiede (z. B. ein Leerzeichen ist
erlaubt, einer Registerkarte zu entsprechen), aber ansonsten wird der Inhalt der "PRÜFEN:"Zeile ist erforderlich, um
stimmt mit etwas in der Testdatei genau überein.

Eine schöne Sache an FileCheck (im Vergleich zu grep) ist, dass es das Zusammenführen von Testfällen ermöglicht
in logische Gruppen zusammenfassen. Zum Beispiel, weil der obige Test auf die
"unter1:" und "inkl4:" Labels, es wird nicht übereinstimmen, es sei denn, es gibt ein "Kursivschrift"dazwischen
Etiketten. Wenn es an anderer Stelle in der Datei vorhanden wäre, würde das nicht zählen: "grep Kursivschrift"
stimmt überein, wenn "Kursivschrift" existiert überall in der Datei.

Das Dateiprüfung -Check-Präfix zu erhalten
Der FileCheck -Check-Präfix Option ermöglicht das Fahren mehrerer Testkonfigurationen von
dank One .NS Datei. Dies ist in vielen Fällen nützlich, zum Beispiel beim Testen verschiedener
architektonische Varianten mit Llc. Hier ist ein einfaches Beispiel:

; AUSFÜHREN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
; LAUF: | FileCheck %s -check-prefix=X32
; AUSFÜHREN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
; LAUF: | FileCheck %s -check-prefix=X64

define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
%tmp1 = Einfügeelement <4 x i32>; %tmp, i32 %s, i32 1
ret <4 x i32> %tmp1
; X32: pinrd_1:
; X32: pinrd $1, 4(%esp), %xmm0

; X64: pinrd_1:
; X64: pinrd $1, %edi, %xmm0
}

In diesem Fall testen wir, ob wir die erwartete Codegenerierung sowohl mit 32-Bit- als auch mit
64-Bit-Codegenerierung.

Das CHECK-WEITER: Richtlinien
Manchmal möchten Sie Zeilen abgleichen und möchten überprüfen, ob Übereinstimmungen genau an denen stattfinden
aufeinanderfolgende Zeilen ohne weitere Zeilen dazwischen. In diesem Fall können Sie "PRÜFEN:"
und "CHECK-WEITER:" Anweisungen, um dies anzugeben. Wenn Sie ein benutzerdefiniertes Prüfpräfix angegeben haben,
benutz einfach "-NÄCHSTE:". Zum Beispiel funktioniert so etwas wie erwartet:

define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
%tmp3 = Last <2 x doppelt>* %A, ausrichten 16
%tmp7 = insertelement <2 x double> undef, double %B, i32 0
%tmp9 = Mischvektor <2 x doppelt> %tmp3,
<2 x doppelt> %tmp7,
<2 x i32> < i32 0, i32 2 >
speichern <2 x doppelt> %tmp9, <2 x doppelt>* %r, ausrichten 16
ret nichtig

; PRÜFEN: t2:
; PRÜFEN: movl 8(%esp), %eax
; CHECK-WEITER: movapd (%eax), %xmm0
; CHECK-WEITER: movhpd 12(%esp), %xmm0
; CHECK-NEXT: movl 4(%esp), %eax
; CHECK-WEITER: movapd %xmm0, (%eax)
; CHECK-WEITER: ret
}

"CHECK-WEITER:"-Anweisungen lehnen die Eingabe ab, es sei denn, es steht genau ein Zeilenumbruch dazwischen
und die vorherige Richtlinie. EIN "CHECK-WEITER:" kann nicht die erste Direktive in einer Datei sein.

Das ÜBERPRÜFEN-NICHT: Richtlinien
Die "ÜBERPRÜFEN-NICHT:"-Direktive wird verwendet, um zu überprüfen, dass keine Zeichenfolge zwischen zwei auftritt
Matches (oder vor dem ersten Match oder nach dem letzten Match). Um zum Beispiel zu überprüfen, dass
Wird eine Last durch eine Transformation entfernt, kann ein Test wie dieser verwendet werden:

definiere i8 @coerce_offset0(i32 %V, i32* %P) {
i32 %V, i32* %P . speichern

%P2 = Bitcast i32* %P bis i8*
%P3 = getelementptr i8* %P2, i32 2

%A = Last i8* %P3
ret i8 %A
; PRÜFEN: @coerce_offset0
; CHECK-NOT: laden
; PRÜFEN: ret i8
}

Das KONTROLLTAG: Richtlinien
Wenn Zeichenfolgen abgeglichen werden müssen, die nicht in einer streng sequentiellen Reihenfolge vorkommen,
"KONTROLLTAG:" könnte verwendet werden, um sie zwischen zwei Matches (oder vor dem ersten Match,
oder nach dem letzten Spiel). Zum Beispiel gibt clang vtable-Globals in umgekehrter Reihenfolge aus. Verwenden von
KONTROLLTAG:, können wir die Prüfungen in der natürlichen Reihenfolge halten:

// AUSFÜHREN: %clang_cc1 %s -emit-llvm -o - | DateiCheck %s

struct Foo { virtuelle Void-Methode (); };
Foo f; // vtable ausgeben
// CHECK-DAG: @_ZTV3Foo =

Struct Bar {Virtual Void-Methode (); };
Balken b;
// CHECK-DAG: @_ZTV3Bar =

ÜBERPRÜFEN-NICHT: Richtlinien könnten gemischt werden mit KONTROLLTAG: Anweisungen zum Ausschließen von Zeichenfolgen zwischen
das Umfeld KONTROLLTAG: Richtlinien. Dadurch wird die Umgebung KONTROLLTAG: Richtlinien
kann nicht neu geordnet werden, dh alle Vorkommen stimmen überein KONTROLLTAG: Bevor ÜBERPRÜFEN-NICHT: Muss nicht
zurückfallen Vorkommnisse übereinstimmend KONTROLLTAG: nachdem ÜBERPRÜFEN-NICHT:. Beispielsweise,

; CHECK-DAG: VORHER
; CHECK-NOT: NICHT
; CHECK-DAG: NACHHER

In diesem Fall werden Eingabezeichenfolgen abgelehnt, bei denen VOR tritt nach AFTER.

Mit erfassten Variablen, KONTROLLTAG: ist in der Lage, gültige topologische Ordnungen eines DAG . abzugleichen
mit Kanten von der Definition einer Variablen bis zu ihrer Verwendung. Es ist nützlich, z. B. wenn Ihr
Testfälle müssen mit unterschiedlichen Ausgabesequenzen aus dem Instruktions-Scheduler übereinstimmen. Zum
Beispiel

; CHECK-DAG: addiere [[REG1:r[0-9]+]], r1, r2
; CHECK-DAG: addiere [[REG2:r[0-9]+]], r3, r4
; PRÜFEN: mul r5, [[REG1]], [[REG2]]

In diesem Fall ist jede Reihenfolge dieser beiden hinzufügen Anweisungen werden erlaubt.

Wenn du definierst und Verwenden von Variablen im selben KONTROLLTAG: blockieren, beachten Sie, dass die
Definitionsregel kann übereinstimmen nachdem sein Nutzen.

So wird beispielsweise der folgende Code übergeben:

; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
; CHECK-DAG: vmov.32 [[REG2]][1]
vmov.32 d0[1]
vmov.32 d0[0]

Während dieser andere Code nicht:

; CHECK-DAG: vmov.32 [[REG2:d[0-9]+]][0]
; CHECK-DAG: vmov.32 [[REG2]][1]
vmov.32 d1[1]
vmov.32 d0[0]

Dies kann zwar sehr nützlich sein, ist aber auch gefährlich, denn im Falle einer Registrierung
Sie müssen eine strenge Reihenfolge haben (Lesen vor dem Schreiben, Kopieren vor der Verwendung usw.). Wenn die
Definition, nach der Ihr Test sucht, stimmt nicht überein (aufgrund eines Fehlers im Compiler), es
kann weiter weg von der Verwendung passen und echte Fehler maskieren.

Verwenden Sie in diesen Fällen eine Nicht-DAG-Direktive zwischen DAG-Blöcken, um die Reihenfolge durchzusetzen.

Das CHECK-ETIKETTEN: Richtlinien
Manchmal in einer Datei, die mehrere Tests enthält, die in logische Blöcke unterteilt sind, einer oder mehrere
PRÜFEN: Direktiven können versehentlich erfolgreich sein, indem Zeilen in einem späteren Block übereinstimmen. Während ein
Fehler wird normalerweise irgendwann generiert, die Prüfung, die als Fehlerursache gekennzeichnet ist, kann es nicht sein
tatsächlich in irgendeiner Beziehung zur eigentlichen Ursache des Problems stehen.

Um in diesen Fällen bessere Fehlermeldungen zu erzeugen, wird die "CHECK-ETIKETTEN:"Direktive kann
verwendet werden. Es wird genauso behandelt wie ein normales Check Anweisung, außer dass FileCheck macht
eine zusätzliche Annahme, dass eine Zeile, die von der Direktive übereinstimmt, nicht auch von
jeder andere Scheck vorhanden in Match-Dateiname; dies soll für Linien verwendet werden
Labels oder andere eindeutige Identifikatoren enthalten. Konzeptionell ist das Vorhandensein von CHECK-ETIKETTEN
teilt den Eingabestrom in separate Blöcke auf, von denen jeder unabhängig verarbeitet wird,
verhindern PRÜFEN: Direktive in einem Block, die einer Zeile in einem anderen Block entspricht. Zum Beispiel,

definiere %struct.C* @C_ctor_base(%struct.C* %this, i32 %x) {
Eintrag:
; CHECK-LABEL: C_ctor_base:
; PRÜFEN: mov [[SAVETHIS:r[0-9]+]], r0
; PRÜFEN: bl A_ctor_base
; PRÜFEN: mov r0, [[SAVETHIS]]
%0 = Bitcast %struct.C* %this zu %struct.A*
%call = Rückruf %struct.A* @A_ctor_base(%struct.A* %0)
%1 = Bitcast %struct.C* %this zu %struct.B*
%call2 = Rückruf %struct.B* @B_ctor_base(%struct.B* %1, i32 %x)
ret %struct.C* %dies
}

definiere %struct.D* @D_ctor_base(%struct.D* %this, i32 %x) {
Eintrag:
; CHECK-LABEL: D_ctor_base:

Die Verwendung von CHECK-ETIKETTEN: Richtlinien stellt in diesem Fall sicher, dass die drei PRÜFEN: Richtlinien
nur Zeilen akzeptieren, die dem Körper des entsprechen @C_ctor_base Funktion, auch wenn die
Muster stimmen mit Zeilen überein, die später in der Datei gefunden werden. Außerdem, wenn einer dieser drei PRÜFEN:
-Direktiven fehlschlagen, wird FileCheck wiederherstellen, indem es mit dem nächsten Block fortfährt und mehrere
Testfehler, die in einem einzigen Aufruf erkannt werden.

Es gibt keine Anforderung, dass CHECK-ETIKETTEN: Anweisungen enthalten Zeichenfolgen, die entsprechen
tatsächliche syntaktische Labels in einer Quell- oder Ausgabesprache: Sie müssen einfach eindeutig mit a . übereinstimmen
einzelne Zeile in der zu überprüfenden Datei.

CHECK-ETIKETTEN: Direktiven dürfen keine Variablendefinitionen oder Verwendungen enthalten.

Dateiprüfung Schnittmuster Abstimmung Syntax
Die "PRÜFEN:" und "ÜBERPRÜFEN-NICHT:"-Anweisungen benötigen beide ein Muster, das übereinstimmen muss. Für die meisten Verwendungen von
FileCheck, fester String-Matching ist vollkommen ausreichend. Für manche Dinge ein mehr
flexible Form des Matchings erwünscht. Um dies zu unterstützen, können Sie mit FileCheck angeben
reguläre Ausdrücke in übereinstimmenden Strings, umgeben von doppelten Klammern: {{yourregex}}.
Da wir für einen Großteil unserer Arbeit einen festen String-Matching verwenden möchten, hat FileCheck
wurde entwickelt, um das Mischen und Anpassen von festen Strings mit regulären zu unterstützen
Ausdrücke. Dies ermöglicht Ihnen, Dinge wie folgt zu schreiben:

; PRÜFEN: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}

In diesem Fall wird jeder Offset vom ESP-Register zugelassen, und jedes xmm-Register wird
zugelassen werden.

Da reguläre Ausdrücke in doppelte Klammern eingeschlossen sind, unterscheiden sie sich optisch.
und Sie müssen keine Escape-Zeichen in den doppelten Klammern verwenden, wie Sie es in C tun würden.
In dem seltenen Fall, dass Sie doppelte Klammern explizit aus der Eingabe abgleichen möchten, können Sie
benutze etwas hässliches wie {{[{][{]}} als dein Muster.

Dateiprüfung Variablen
Es ist oft nützlich, ein Muster abzugleichen und dann zu überprüfen, ob es später im wieder auftritt
Datei. Für Codegen-Tests kann dies nützlich sein, um jedes Register zuzulassen, aber überprüfen Sie, ob dies
register wird später konsequent verwendet. Um dies zu tun, Dateiprüfung erlaubt benannte Variablen
definiert und in Muster eingefügt. Hier ist ein einfaches Beispiel:

; PRÜFEN: Test5:
; PRÜFEN: notw [[REGISTER:%[az]+]]
; PRÜFEN: andw {{.*}}[[REGISTER]]

Die erste Checkzeile stimmt mit einer Regex überein %[az]+ und fängt es in die Variable ein REGISTRIEREN.
Die zweite Zeile verifiziert, dass was auch immer drin ist REGISTRIEREN tritt später in der Datei nach einem
"und W". Dateiprüfung Variablenreferenzen sind immer in . enthalten [[ ]] Paare und ihre
Namen können mit der Regex gebildet werden [a-zA-Z][a-zA-Z0-9]*. Wenn auf den Namen ein Doppelpunkt folgt,
dann ist es eine Definition der Variablen; andernfalls ist es eine Verwendung.

Dateiprüfung Variablen können mehrfach definiert werden und verwendet immer den neuesten Wert.
Variablen können auch später in derselben Zeile verwendet werden, in der sie definiert wurden. Zum Beispiel:

; PRÜFEN: op [[REG:r[0-9]+]], [[REG]]

Kann nützlich sein, wenn Sie die Operanden von op das gleiche Register zu sein, und es ist egal
genau welches Register es ist.

Dateiprüfung Ausdrücke
Manchmal muss die Ausgabe überprüft werden, die sich auf die Zeilennummern der Match-Datei bezieht.
zB beim Testen der Compiler-Diagnose. Dies führt zu einer gewissen Zerbrechlichkeit des Spiels
Dateistruktur, als "PRÜFEN:" Zeilen enthalten absolute Zeilennummern in derselben Datei, die
müssen aktualisiert werden, wenn sich Zeilennummern aufgrund von Texthinzufügungen oder -löschungen ändern.

Um diesen Fall zu unterstützen, erlaubt FileCheck die Verwendung von [[@LEITUNG]], [[@LINE+ ]],
[[@LEITUNG- ]] Ausdrücke in Mustern. Diese Ausdrücke erweitern sich zu einer Reihe von
Zeile, in der sich ein Muster befindet (mit einem optionalen Integer-Offset).

Auf diese Weise können Übereinstimmungsmuster in der Nähe der relevanten Testlinien platziert werden und relative Linien einschließen
Nummernreferenzen, zum Beispiel:

// PRÜFEN: test.cpp:[[@LINE+4]]:6: Fehler: erwartet ';' nach Deklarator der obersten Ebene
// PRÜFEN-WEITER: {{^int a}}
// PRÜFEN-WEITER: {{^ \^}}
// PRÜFEN-WEITER: {{^ ;}}
int ein

Verwenden Sie FileCheck-3.6 online mit den onworks.net-Diensten