FileCheck-3.6 - Online nel cloud

PROGRAMMA:

NOME

FileCheck - Verificatore di file di corrispondenza del modello flessibile

SINOSSI

File Check nomefile-match [--check-prefisso=XXX] [--strict-spazio bianco]

DESCRIZIONE

File Check legge due file (uno dall'input standard e uno specificato sulla riga di comando)
e usa uno per verificare l'altro. Questo comportamento è particolarmente utile per la testsuite,
che vuole verificare che l'output di qualche strumento (es llc) contiene il previsto
informazioni (ad esempio, un movsd da esp o qualunque cosa sia interessante). Questo è simile
all'utilizzo grep, ma è ottimizzato per la corrispondenza di più input diversi in un file in a
ordine specifico.

I nomefile-match file specifica il file che contiene i modelli da abbinare. Il file
da verificare viene letto dallo standard input a meno che il --file di input viene utilizzata l'opzione.

VERSIONI

-Aiuto Stampa un riepilogo delle opzioni della riga di comando.

--check-prefisso prefisso
FileCheck cerca il contenuto di nomefile-match per i modelli da abbinare. Di
impostazione predefinita, questi modelli sono preceduti da "DAI UN'OCCHIATA:". Se vuoi usare a
prefisso diverso (ad esempio perché lo stesso file di input sta controllando piùdiverse
strumento o opzioni), il --check-prefisso argomento ti permette di specificare uno o più
prefissi da abbinare. I prefissi multipli sono utili per i test che potrebbero cambiare per
diverse opzioni di esecuzione, ma la maggior parte delle linee rimane la stessa.

--file di input Nome del file
File da controllare (il valore predefinito è stdin).

--strict-spazio bianco
Per impostazione predefinita, FileCheck canonicalizza gli spazi bianchi orizzontali di input (spazi e tabulazioni)
che fa sì che ignori queste differenze (uno spazio corrisponderà a una scheda). Il
--strict-spazio bianco argomento disabilita questo comportamento. Le sequenze di fine riga sono
canonizzato in stile UNIX \n in tutte le modalità.

--non-check-implicito cartamodello
Aggiunge controlli negativi impliciti per i modelli specificati tra i controlli positivi.
L'opzione consente di scrivere test più severi senza riempirli di CHECK-NONs.

Per esempio, "--non-check-implicito avvertimento:" può essere utile durante i test diagnostici
messaggi da strumenti che non hanno un'opzione simile a fragore -verificare. Con questo
l'opzione FileCheck verificherà che l'input non contenga avvisi non coperti da
in qualsiasi DAI UN'OCCHIATA: modelli.

-versione
Mostra il numero di versione di questo programma.

EXIT STATUS

If File Check verifica che il file corrisponda ai contenuti previsti, esce con 0.
Altrimenti, se no, o se si verifica un errore, uscirà con un valore diverso da zero.

TUTORIAL

FileCheck viene in genere utilizzato dai test di regressione LLVM, richiamato sulla riga RUN di
la prova. Un semplice esempio di utilizzo di FileCheck da una riga RUN è simile a questo:

; ESEGUI: llvm-as < %s | llc -marzo=x86-64 | FileCheck %s

Questa sintassi dice di reindirizzare il file corrente ("%s") in lvm-as, pipe che in llc, poi
convogliare l'uscita di llc ai miglioramenti File Check. Ciò significa che FileCheck verificherà il suo
input standard (l'output llc) contro l'argomento del nome file specificato (l'originale .LL
file specificato da "%s"). Per vedere come funziona, diamo un'occhiata al resto del .LL filetto
(dopo la riga RUN):

definire void @sub1(i32* %p, i32 %v) {
iscrizione:
; VERIFICA: sub1:
; VERIFICA: subli
%0 = chiamata di coda i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
ret vuoto
}

definire void @inc4(i64* %p) {
iscrizione:
; VERIFICA: inc4:
; VERIFICA: incq
%0 = chiamata di coda i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
ret vuoto
}

Qui puoi vedere alcuni "DAI UN'OCCHIATA:" righe specificate nei commenti. Ora puoi vedere come il file
è convogliato in lvm-as, poi llce l'output del codice macchina è ciò che stiamo verificando.
FileCheck controlla l'output del codice macchina per verificare che corrisponda a quello "DAI UN'OCCHIATA:" Linee
specificare.

La sintassi del "DAI UN'OCCHIATA:" righe è molto semplice: sono stringhe fisse che devono comparire in
ordine. FileCheck per impostazione predefinita ignora le differenze di spazi bianchi orizzontali (ad esempio uno spazio è
consentito di corrispondere a una scheda) ma in caso contrario, il contenuto del "DAI UN'OCCHIATA:" la riga è necessaria per
corrisponde esattamente a qualcosa nel file di test.

Una cosa bella di FileCheck (rispetto a grep) è che consente di unire casi di test
insieme in gruppi logici. Ad esempio, poiché il test sopra sta verificando la presenza di
"sottotitolo 1:" e "inc4:" etichette, non corrisponderà a meno che non ci sia un "sublime"tra quelli
etichette. Se esistesse da qualche altra parte nel file, non conterebbe: "grep sublime"
corrisponde se "sublime" esiste ovunque nel file.

I File Check -check-prefisso opzione
Il FileCheck -check-prefisso l'opzione consente di guidare più configurazioni di test da
prima .LL file. Questo è utile in molte circostanze, ad esempio, test diversi
varianti architettoniche con llc. Ecco un semplice esempio:

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

define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) sostantivo {
%tmp1 = inserisci elemento <4 x i32>; %tmp, i32 %s, i32 1
ret <4 x i32> %tmp1
; X32: pinrd_1:
; X32: pinsrd $1, 4(%esp), %xmm0

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

In questo caso, stiamo testando di ottenere la generazione di codice prevista sia con 32 bit che con
Generazione di codice a 64 bit.

I CONTROLLA IL PROSSIMO: Direttive
A volte vuoi abbinare le linee e vorresti verificare che le corrispondenze avvengano esattamente
righe consecutive senza altre righe intermedie. In questo caso, puoi usare "DAI UN'OCCHIATA:"
e "CONTROLLA IL PROSSIMO:" per specificarlo. Se hai specificato un prefisso di controllo personalizzato,
usa solo "-PROSSIMO:". Ad esempio, qualcosa del genere funziona come ti aspetteresti:

define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
%tmp3 = carica <2 x doppio>* %A, allinea 16
%tmp7 = elemento di inserimento <2 x double> undef, double %B, i32 0
%tmp9 = vettore casuale <2 x doppio> %tmp3,
<2 x doppio> %tmp7,
<2 x i32> < i32 0, i32 2 >
memorizza <2 x double> %tmp9, <2 x double>* %r, allinea 16
ret vuoto

; VERIFICA: t2:
; VERIFICA: movl 8(%esp), %eax
; VERIFICA-AVANTI: movapd (%eax), %xmm0
; VERIFICA SUCCESSIVO: movhpd 12(%esp), %xmm0
; CHECK-NEXT: movl 4(%esp), %eax
; VERIFICA-AVANTI: movapd %xmm0, (%eax)
; VERIFICA-AVANTI: ret
}

"CONTROLLA IL PROSSIMO:" le direttive rifiutano l'input a meno che non ci sia esattamente una nuova riga tra di esso
e la precedente direttiva. UN "CONTROLLA IL PROSSIMO:" non può essere la prima direttiva in un file.

I CHECK-NON: Direttive
Il "CHECK-NON:" viene utilizzata per verificare che non si verifichi una stringa tra due
partite (o prima della prima partita, o dopo l'ultima partita). Ad esempio, per verificare che
un carico viene rimosso da una trasformazione, è possibile utilizzare un test come questo:

definire i8 @coerce_offset0(i32 %V, i32* %P) {
memorizzare i32 %V, i32* %P

%P2 = bitcast i32* %P a i8*
%P3 = getelementptr i8* %P2, i32 2

%A = carico i8* %P3
ret i8%A
; VERIFICA: @coerce_offset0
; CHECK-NOT: carico
; VERIFICA: ret i8
}

I CHECK-DAG: Direttive
Se è necessario abbinare stringhe che non si verificano in un ordine strettamente sequenziale,
"CHECK-DAG:" potrebbe essere usato per verificarli tra due partite (o prima della prima partita,
o dopo l'ultima partita). Ad esempio, clang emette vtable globali in ordine inverso. Usando
CHECK-DAG:, possiamo mantenere i controlli nell'ordine naturale:

// ESEGUI: %clang_cc1 %s -emit-llvm -o - | FileCheck %s

struct Foo { metodo void virtuale(); };
Foo f; // emette vtable
// CHECK-DAG: @_ZTV3Foo =

struct Bar { metodo void virtuale(); };
barra b;
// CHECK-DAG: @_ZTV3Bar =

CHECK-NON: le direttive potrebbero essere mescolate con CHECK-DAG: direttive per escludere le stringhe tra
i dintorni CHECK-DAG: direttive. Di conseguenza, l'ambiente circostante CHECK-DAG: direttive
non può essere riordinato, ovvero tutte le occorrenze corrispondono CHECK-DAG: prima CHECK-NON: non deve
rimanere indietro rispetto alle occorrenze corrispondenti CHECK-DAG: dopo CHECK-NON:. Per esempio,

; CHECK-DAG: PRIMA
; CHECK-NOT: NON
; CHECK-DAG: DOPO

Questo caso rifiuterà le stringhe di input dove PRIMA si verifica dopo DOPO.

Con le variabili catturate, CHECK-DAG: è in grado di abbinare ordinamenti topologici validi di un DAG
con bordi dalla definizione di una variabile al suo utilizzo. È utile, ad esempio, quando il tuo
i casi di test devono corrispondere a diverse sequenze di output dallo scheduler delle istruzioni. Per
esempio,

; CHECK-DAG: aggiungi [[REG1:r[0-9]+]], r1, r2
; CHECK-DAG: aggiungi [[REG2:r[0-9]+]], r3, r4
; VERIFICA: mul r5, [[REG1]], [[REG2]]

In questo caso, qualsiasi ordine di quei due aggiungere le istruzioni saranno consentite.

Se stai definendo ed usando le variabili nello stesso CHECK-DAG: blocco, essere consapevoli che il
la regola di definizione può corrispondere dopo il suo utilizzo.

Quindi, ad esempio, passerà il codice seguente:

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

Mentre questo altro codice, non:

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

Anche se questo può essere molto utile, è anche pericoloso, perché nel caso del registro
sequenza, devi avere un ordine forte (leggi prima di scrivere, copia prima dell'uso, ecc.). Se la
definizione che il tuo test sta cercando non corrisponde (a causa di un bug nel compilatore), è
può corrispondere più lontano dall'uso e mascherare i bug reali.

In questi casi, per far rispettare l'ordine, utilizzare una direttiva non DAG tra i blocchi DAG.

I VERIFICA ETICHETTA: Direttive
A volte in un file contenente più test divisi in blocchi logici, uno o più
DAI UN'OCCHIATA: le direttive possono inavvertitamente avere successo facendo corrispondere le righe in un blocco successivo. mentre an
di solito alla fine verrà generato un errore, il controllo contrassegnato come causa dell'errore potrebbe non essere
hanno effettivamente alcun rapporto con la fonte effettiva del problema.

Per produrre messaggi di errore migliori in questi casi, il "VERIFICA ETICHETTA:" direttiva può
essere usato. È trattato in modo identico a un normale CONTROLLO direttiva tranne che FileCheck rende
un'ulteriore assunzione che una riga soddisfatta dalla direttiva non può essere abbinata anche da
qualsiasi altro assegno presente in nomefile-match; questo è destinato ad essere utilizzato per le linee
contenenti etichette o altri identificatori univoci. Concettualmente, la presenza di CHECK-ETICHETTA
divide il flusso di input in blocchi separati, ognuno dei quali viene elaborato in modo indipendente,
prevenire un DAI UN'OCCHIATA: direttiva in un blocco che corrisponde a una riga in un altro blocco. Per esempio,

define %struct.C* @C_ctor_base(%struct.C* %this, i32 %x) {
iscrizione:
; ETICHETTA DI CONTROLLO: C_ctor_base:
; VERIFICA: mov [[SAVETHIS:r[0-9]+]], r0
; VERIFICA: bl A_ctor_base
; VERIFICA: mov r0, [[SAVETHIS]]
%0 = bitcast %struct.C* %this a %struct.A*
%call = chiamata in coda %struct.A* @A_ctor_base(%struct.A* %0)
%1 = bitcast %struct.C* %this a %struct.B*
%call2 = chiamata in coda %struct.B* @B_ctor_base(%struct.B* %1, i32 %x)
ret %struct.C* %this
}

define %struct.D* @D_ctor_base(%struct.D* %this, i32 %x) {
iscrizione:
; ETICHETTA DI CONTROLLO: D_ctor_base:

L'impiego di VERIFICA ETICHETTA: direttive in questo caso assicura che i tre DAI UN'OCCHIATA: direttive
accettare solo le righe corrispondenti al corpo del @C_ctor_base funzione, anche se
i pattern corrispondono alle linee trovate più avanti nel file. Inoltre, se uno di questi tre DAI UN'OCCHIATA:
le direttive falliscono, FileCheck si riprenderà continuando al blocco successivo, consentendo più
errori di test da rilevare in una singola chiamata.

Non c'è nessun requisito che VERIFICA ETICHETTA: le direttive contengono stringhe che corrispondono a
etichette sintattiche effettive in una lingua di origine o di output: devono semplicemente corrispondere in modo univoco a
singola riga nel file in fase di verifica.

VERIFICA ETICHETTA: le direttive non possono contenere definizioni o usi di variabili.

File Check Cartamodello accoppiamento Sintassi
Il "DAI UN'OCCHIATA:" e "CHECK-NON:" entrambe le direttive richiedono un modello da abbinare. Per la maggior parte degli usi di
FileCheck, la corrispondenza delle stringhe fisse è perfettamente sufficiente. Per alcune cose, un di più
si desidera una forma flessibile di abbinamento. Per supportare ciò, FileCheck ti consente di specificare
espressioni regolari nelle stringhe corrispondenti, racchiuse tra doppie parentesi: {{yourregex}}.
Poiché vogliamo utilizzare la corrispondenza di stringhe fisse per la maggior parte di ciò che facciamo, FileCheck ha
stato progettato per supportare la miscelazione e l'abbinamento di stringhe fisse con regolari
espressioni. Questo ti permette di scrivere cose come questa:

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

In questo caso, sarà consentito qualsiasi offset dal registro ESP e qualsiasi registro xmm sarà
essere permesso.

Poiché le espressioni regolari sono racchiuse tra doppie parentesi graffe, sono visivamente distinte,
e non è necessario utilizzare caratteri di escape all'interno delle doppie parentesi come faresti in C.
Nel raro caso in cui desideri abbinare le doppie parentesi esplicitamente dall'input, puoi
usa qualcosa di brutto come {{[{][{]}} come il tuo modello.

File Check Variabili
Spesso è utile far corrispondere un pattern e poi verificare che si ripeta più tardi nel
file. Per i test di codegen, questo può essere utile per consentire qualsiasi registro, ma verifica che
registro viene utilizzato in modo coerente in seguito. Per fare questo, File Check consente alle variabili denominate di essere
definiti e sostituiti in schemi. Qui c'è un semplice esempio:

; VERIFICA: prova5:
; VERIFICA: ora [[REGISTRAZIONE:%[az]+]]
; VERIFICA: ew {{.*}}[[REGISTRATI]]

La prima riga di controllo corrisponde a un'espressione regolare %[az]+ e lo cattura nella variabile REGISTRATI.
La seconda riga verifica che qualunque cosa sia in REGISTRATI si verifica più avanti nel file dopo an
"e W". File Check i riferimenti alle variabili sono sempre contenuti in [[ ]] coppie, e loro
i nomi possono essere formati con l'espressione regolare [a-zA-Z][a-zA-Z0-9]*. Se i due punti seguono il nome,
allora è una definizione della variabile; altrimenti è un uso.

File Check le variabili possono essere definite più volte e gli usi ottengono sempre il valore più recente.
Le variabili possono essere utilizzate anche in seguito sulla stessa riga in cui sono state definite. Per esempio:

; VERIFICA: op [[REG:r[0-9]+]], [[REG]]

Può essere utile se vuoi gli operandi di op essere lo stesso registro, e non importa
esattamente che registro è.

File Check Espressioni
A volte è necessario verificare l'output che fa riferimento ai numeri di riga del file di corrispondenza,
ad es. durante il test della diagnostica del compilatore. Questo introduce una certa fragilità del match
struttura del file, come "DAI UN'OCCHIATA:" le righe contengono numeri di riga assoluti nello stesso file, che
devono essere aggiornati ogni volta che i numeri di riga cambiano a causa dell'aggiunta o dell'eliminazione del testo.

Per supportare questo caso, FileCheck consente di utilizzare [[@LINEA]], [[@LINE+ ]],
[[@LINEA- ]] espressioni in schemi. Queste espressioni si espandono a un certo numero di
riga in cui si trova un motivo (con un offset intero opzionale).

In questo modo i modelli di corrispondenza possono essere posizionati vicino alle linee di test pertinenti e includere la linea relativa
riferimenti numerici, ad esempio:

// VERIFICA: test.cpp:[[@LINE+4]]:6: errore: previsto ';' dopo il dichiaratore di primo livello
// CONTROLLA-NEXT: {{^int a}}
// VERIFICA SUCCESSIVO: {{^ \^}}
// VERIFICA SUCCESSIVO: {{^ ;}}
int a

Utilizzare FileCheck-3.6 online utilizzando i servizi onworks.net