FileCheck-3.6 - En ligne dans le Cloud

PROGRAMME:

Nom

FileCheck - Vérificateur de fichier de correspondance de modèle flexible

SYNOPSIS

Contrôle de fichier match-nom-de-fichier [--check-prefix=XXX] [--strict-espace blanc]

DESCRIPTION

Contrôle de fichier lit deux fichiers (un à partir de l'entrée standard et un spécifié sur la ligne de commande)
et utilise l'un pour vérifier l'autre. Ce comportement est particulièrement utile pour la suite de tests,
qui veut vérifier que la sortie d'un outil (par exemple llc) contient l'attendu
informations (par exemple, un movsd d'esp ou tout ce qui est intéressant). C'est similaire
à l'aide de grep, mais il est optimisé pour faire correspondre plusieurs entrées différentes dans un fichier dans un
commande spécifique.

La match-nom-de-fichier file spécifie le fichier qui contient les modèles à faire correspondre. Le fichier
à vérifier est lu à partir de l'entrée standard à moins que le --fichier-d'entrée option est utilisée.

OPTIONS

-Aide Imprimez un résumé des options de la ligne de commande.

--vérifier-préfixe préfixe
FileCheck recherche le contenu de match-nom-de-fichier pour que les motifs correspondent. Par
par défaut, ces motifs sont préfixés par "VÉRIFIER:". Si vous souhaitez utiliser un
préfixe différent (par exemple parce que le même fichier d'entrée vérifie plusieurs
outil ou options), le --vérifier-préfixe l'argument vous permet de spécifier un ou plusieurs
préfixes correspondants. Les préfixes multiples sont utiles pour les tests qui peuvent changer pour
différentes options d'exécution, mais la plupart des lignes restent les mêmes.

--fichier-d'entrée nom de fichier
Fichier à vérifier (par défaut, stdin).

--strict-espace blanc
Par défaut, FileCheck canonise les espaces horizontaux d'entrée (espaces et tabulations)
ce qui lui fait ignorer ces différences (un espace correspondra à une tabulation). Les
--strict-espace blanc L'argument désactive ce comportement. Les séquences de fin de ligne sont
canonisé au style UNIX \n dans tous les modes.

--implicit-check-not motif de contrôle
Ajoute des vérifications négatives implicites pour les modèles spécifiés entre les vérifications positives.
L'option permet d'écrire des tests plus stricts sans les bourrer de VÉRIFIER NONs.

Par exemple, "--implicit-check-not Attention:" peut être utile lors des tests de diagnostic
messages provenant d'outils qui n'ont pas d'option similaire à bruit -Vérifier. Avec ça
L'option FileCheck vérifiera que l'entrée ne contient pas d'avertissements non couverts par
tous VÉRIFIER: modèles

-version
Affiche le numéro de version de ce programme.

EXIT STATUT

If Contrôle de fichier vérifie que le fichier correspond au contenu attendu, il se termine par 0.
Sinon, sinon, ou si une erreur se produit, il se terminera avec une valeur non nulle.

TUTORIAL

FileCheck est généralement utilisé à partir des tests de régression LLVM, étant invoqué sur la ligne RUN de
le test. Un exemple simple d'utilisation de FileCheck à partir d'une ligne RUN ressemble à ceci :

; RUN : llvm-as < %s | llc -march=x86-64 | Vérification de fichier %s

Cette syntaxe dit de diriger le fichier courant ("%s") dans llvm-as, insérez-le dans llc, puis
canaliser la sortie de llc développement Contrôle de fichier. Cela signifie que FileCheck vérifiera son
entrée standard (la sortie llc) par rapport à l'argument de nom de fichier spécifié (l'original .ll
fichier spécifié par "%s"). Pour voir comment cela fonctionne, regardons le reste du .ll filet
(après la ligne RUN) :

définir le vide @sub1(i32* %p, i32 %v) {
entrée:
; VÉRIFIER : sub1 :
; VÉRIFIER : subl
%0 = appel de queue i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
vide
}

définir le vide @inc4(i64* %p) {
entrée:
; VÉRIFIER : inc4 :
; VÉRIFIER : incq
%0 = appel de queue i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
vide
}

Ici vous pouvez voir quelques "VÉRIFIER:" lignes spécifiées dans les commentaires. Vous pouvez maintenant voir comment le fichier
est canalisé dans llvm-as, puis llc, et la sortie du code machine est ce que nous vérifions.
FileCheck vérifie la sortie du code machine pour vérifier qu'elle correspond à ce que "VÉRIFIER:" lignes
spécifier.

La syntaxe du "VÉRIFIER:" lignes est très simple : ce sont des chaînes fixes qui doivent apparaître dans
ordre. FileCheck ignore par défaut les différences d'espaces horizontaux (par exemple, un espace est
autorisé à correspondre à un onglet) mais sinon, le contenu du "VÉRIFIER:La ligne " est requise pour
correspond exactement à quelque chose dans le fichier de test.

Une bonne chose à propos de FileCheck (par rapport à grep) est qu'il permet de fusionner les cas de test
ensemble en groupes logiques. Par exemple, parce que le test ci-dessus vérifie le
"sous1 :" et "inc4 :" étiquettes, il ne correspondra pas à moins qu'il n'y ait un "sub" entre ceux
Étiquettes. S'il existait ailleurs dans le fichier, cela ne compterait pas : "grep sub"
correspond si "sub" existe n'importe où dans le fichier.

La Contrôle de fichier -vérifier le préfixe option
La vérification de fichier -vérifier le préfixe L'option permet de piloter plusieurs configurations de test à partir de
UN .ll déposer. Ceci est utile dans de nombreuses circonstances, par exemple, pour tester différents
variantes architecturales avec llc. Voici un exemple simple :

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

définir <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
%tmp1 = élément d'insertion <4 x i32> ; %tmp, i32 %s, i32 1
ret <4 x i32> %tmp1
; X32 : pinsrd_1 :
; X32 : pinsrd $1, 4(%esp), %xmm0

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

Dans ce cas, nous testons que nous obtenons la génération de code attendue avec 32 bits et
Génération de code 64 bits.

La CHECK-NEXT : directive
Parfois, vous souhaitez faire correspondre des lignes et souhaitez vérifier que les correspondances se produisent exactement
lignes consécutives sans aucune autre ligne entre elles. Dans ce cas, vous pouvez utiliser "VÉRIFIER:"
et "CHECK-NEXT :" pour spécifier cela. Si vous avez spécifié un préfixe de contrôle personnalisé,
il suffit d'utiliser "-SUIVANT:". Par exemple, quelque chose comme ceci fonctionne comme vous vous en doutez :

define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
%tmp3 = charge <2 x double>* %A, aligner 16
%tmp7 = insertelement <2 x double> undef, double %B, i32 0
%tmp9 = shufflevector <2 x double> %tmp3,
<2 x double> %tmp7,
<2 x i32> < i32 0, i32 2 >
stocker <2 x double> %tmp9, <2 x double>* %r, aligner 16
vide

; VÉRIFIER : t2 :
; VÉRIFIER : movl 8(%esp), %eax
; CHECK-NEXT : movapd (%eax), %xmm0
; CHECK-NEXT : movhpd 12(%esp), %xmm0
; CHECK-NEXT : movl 4(%esp), %eax
; CHECK-NEXT : movapd %xmm0, (%eax)
; CHECK-NEXT : ret
}

"CHECK-NEXT :" les directives rejettent l'entrée à moins qu'il n'y ait exactement une nouvelle ligne entre elle
et la directive précédente. UNE "CHECK-NEXT :" ne peut pas être la première directive d'un fichier.

La CHECK-NOT : directive
"CHECK-NOT :La directive " est utilisée pour vérifier qu'une chaîne ne se produit pas entre deux
matchs (ou avant le premier match, ou après le dernier match). Par exemple, pour vérifier que
une charge est supprimée par une transformation, un test comme celui-ci peut être utilisé :

définir i8 @coerce_offset0(i32 %V, i32* %P) {
mémoriser i32 %V, i32* %P

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

%A = charge i8* %P3
retraité i8 %A
; VÉRIFIER : @ coerce_offset0
; CHECK-NOT : charger
; VÉRIFIER : ret i8
}

La CHECK-DAG : directive
S'il est nécessaire de faire correspondre des chaînes qui n'apparaissent pas dans un ordre strictement séquentiel,
"CHECK-DAG :" pourrait être utilisé pour les vérifier entre deux matchs (ou avant le premier match,
ou après le dernier match). Par exemple, clang émet des globals vtable dans l'ordre inverse. À l'aide de
CHECK-DAG :, on peut garder les chèques dans l'ordre naturel :

// RUN : %clang_cc1 %s -emit-llvm -o - | Vérification de fichier %s

struct Foo { virtual void method(); } ;
Foo f; // émet vtable
// CHECK-DAG : @_ZTV3Foo =

struct Bar { méthode de vide virtuel (); } ;
Barre b ;
// CHECK-DAG : @_ZTV3Bar =

CHECK-NOT : les directives pourraient être mélangées avec CHECK-DAG : directives pour exclure les chaînes entre
les alentours CHECK-DAG : directives. En conséquence, les environs CHECK-DAG : directives
ne peut pas être réordonné, c'est-à-dire que toutes les occurrences correspondent CHECK-DAG : before CHECK-NOT : ne doit pas
prendre du retard sur les occurrences correspondant CHECK-DAG : après CHECK-NOT :. Par exemple,

; CHECK-DAG : AVANT
; CHECK-NOT : PAS
; CHECK-DAG : APRÈS

Ce cas rejettera les chaînes d'entrée où AVANT DE se produit après APRÈS.

Avec des variables capturées, CHECK-DAG : est capable de faire correspondre les ordres topologiques valides d'un DAG
avec des bords depuis la définition d'une variable jusqu'à son utilisation. C'est utile, par exemple, lorsque votre
Les cas de test doivent correspondre à différentes séquences de sortie du planificateur d'instructions. Pour
Par exemple,

; CHECK-DAG : ajouter [[REG1:r[0-9]+]], r1, r2
; CHECK-DAG : ajouter [[REG2:r[0-9]+]], r3, r4
; VÉRIFIER : mul r5, [[REG1]], [[REG2]]

Dans ce cas, tout ordre de ces deux ajouter les instructions seront autorisées.

Si vous définissez ainsi que en utilisant des variables dans le même CHECK-DAG : bloquer, sachez que le
la règle de définition peut correspondre après Son usage.

Ainsi, par exemple, le code ci-dessous passera :

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

Bien que cet autre code ne :

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

Bien que cela puisse être très utile, c'est aussi dangereux, car dans le cas du registre
séquence, vous devez avoir un ordre fort (lire avant d'écrire, copier avant utilisation, etc.). Si la
définition que votre test recherche ne correspond pas (à cause d'un bogue dans le compilateur), il
peut correspondre plus loin de l'utilisation et masquer les vrais bogues.

Dans ces cas, pour appliquer l'ordre, utilisez une directive non DAG entre les blocs DAG.

La VÉRIFIER L'ÉTIQUETTE : directive
Parfois dans un fichier contenant plusieurs tests divisés en blocs logiques, un ou plusieurs
VÉRIFIER: les directives peuvent réussir par inadvertance en faisant correspondre des lignes dans un bloc ultérieur. Alors qu'un
l'erreur sera généralement générée, la vérification signalée comme étant à l'origine de l'erreur peut ne pas
n'ont en fait aucune relation avec la source réelle du problème.

Afin de produire de meilleurs messages d'erreur dans ces cas, le "VÉRIFIER L'ÉTIQUETTE :" directive peut
être utilisé. Elle est traitée de la même manière qu'une normale COMMENCER directive sauf que FileCheck fait
une hypothèse supplémentaire selon laquelle une ligne correspondant à la directive ne peut pas également être mise en correspondance par
tout autre chèque présent dans match-nom-de-fichier; ceci est destiné à être utilisé pour les lignes
contenant des étiquettes ou d'autres identifiants uniques. Conceptuellement, la présence de VÉRIFIER-ÉTIQUETTE
divise le flux d'entrée en blocs séparés, dont chacun est traité indépendamment,
empêcher un VÉRIFIER: directive dans un bloc correspondant à une ligne dans un autre bloc. Par exemple,

définir %struct.C* @C_ctor_base(%struct.C* %this, i32 %x) {
entrée:
; CHECK-LABEL : C_ctor_base :
; VÉRIFIER : mov [[SAVETHIS :r[0-9]+]], r0
; VÉRIFIER : bl A_ctor_base
; VÉRIFIER : mov r0, [[SAVETHIS]]
%0 = bitcast %struct.C* %this vers %struct.A*
%call = appel de queue %struct.A* @A_ctor_base(%struct.A* %0)
%1 = bitcast %struct.C* %this vers %struct.B*
%call2 = appel de queue %struct.B* @B_ctor_base(%struct.B* %1, i32 %x)
ret %struct.C* %this
}

définir %struct.D* @D_ctor_base(%struct.D* %this, i32 %x) {
entrée:
; CHECK-LABEL : D_ctor_base :

L'utilisation de VÉRIFIER L'ÉTIQUETTE : directives dans ce cas garantit que les trois VÉRIFIER: directives
n'accepte que les lignes correspondant au corps du @C_ctor_base fonction, même si le
les motifs correspondent aux lignes trouvées plus tard dans le fichier. De plus, si l'un de ces trois VÉRIFIER:
échouent, FileCheck récupérera en passant au bloc suivant, permettant plusieurs
les échecs de test doivent être détectés en un seul appel.

Il n'y a aucune exigence que VÉRIFIER L'ÉTIQUETTE : les directives contiennent des chaînes qui correspondent à
étiquettes syntaxiques réelles dans une langue source ou de sortie : elles doivent simplement correspondre de manière unique à un
une seule ligne dans le fichier en cours de vérification.

VÉRIFIER L'ÉTIQUETTE : les directives ne peuvent pas contenir de définitions ou d'utilisations de variables.

Contrôle de fichier Patron de Couture Des Syntaxe
"VÉRIFIER:" et "CHECK-NOT :Les directives " prennent toutes les deux un modèle pour correspondre. Pour la plupart des utilisations de
FileCheck, la correspondance de chaîne fixe est parfaitement suffisante. Pour certaines choses, un plus
une forme flexible d'appariement est souhaitée. Pour prendre en charge cela, FileCheck vous permet de spécifier
expressions régulières dans les chaînes correspondantes, entourées de doubles accolades : {{yourregex}}.
Parce que nous voulons utiliser une correspondance de chaîne fixe pour la majorité de ce que nous faisons, FileCheck a
a été conçu pour prendre en charge le mélange et la correspondance de chaînes fixes avec des chaînes régulières
expressions. Cela vous permet d'écrire des choses comme ceci :

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

Dans ce cas, tout décalage par rapport au registre ESP sera autorisé, et tout registre xmm sera
être autorisé.

Les expressions régulières étant entourées de doubles accolades, elles sont visuellement distinctes,
et vous n'avez pas besoin d'utiliser des caractères d'échappement dans les doubles accolades comme vous le feriez en C.
Dans les rares cas où vous souhaitez faire correspondre explicitement des accolades doubles à partir de l'entrée, vous pouvez
utiliser quelque chose de laid comme {{[{][{]}} comme modèle.

Contrôle de fichier Variables
Il est souvent utile de faire correspondre un modèle, puis de vérifier qu'il se reproduit plus tard dans la
déposer. Pour les tests de codegen, cela peut être utile pour autoriser n'importe quel registre, mais vérifiez que cela
registre est utilisé systématiquement plus tard. Pour faire ça, Contrôle de fichier permet aux variables nommées d'être
définis et substitués dans des modèles. Voici un exemple simple :

; VÉRIFIER : test5 :
; VÉRIFIER : notw [[INSCRIRE : %[az]+]]
; VÉRIFIER : andw {{.*}}[[INSCRIRE]]

La première ligne de contrôle correspond à une expression régulière %[az]+ et le capture dans la variable S'INSCRIRE.
La deuxième ligne vérifie que tout ce qui est dans S'INSCRIRE se produit plus tard dans le fichier après un
"et W". Contrôle de fichier les références de variables sont toujours contenues dans [[ ]] paires, et leurs
les noms peuvent être formés avec le regex [a-zA-Z][a-zA-Z0-9]*. Si deux points suivent le nom,
alors c'est une définition de la variable ; sinon, c'est une utilisation.

Contrôle de fichier les variables peuvent être définies plusieurs fois et les utilisations obtiennent toujours la dernière valeur.
Les variables peuvent également être utilisées ultérieurement sur la même ligne sur laquelle elles ont été définies. Par exemple:

; VÉRIFIER : op [[REG:r[0-9]+]], [[REG]]

Peut être utile si vous voulez les opérandes de op être le même registre, et s'en fiche
exactement de quel registre il s'agit.

Contrôle de fichier Expressions
Parfois, il est nécessaire de vérifier la sortie qui fait référence aux numéros de ligne du fichier de correspondance,
par exemple lors du test des diagnostics du compilateur. Cela introduit une certaine fragilité du match
structure de fichier, comme "VÉRIFIER:Les lignes " contiennent des numéros de ligne absolus dans le même fichier, ce qui
doivent être mis à jour chaque fois que les numéros de ligne changent en raison de l'ajout ou de la suppression de texte.

Pour prendre en charge ce cas, FileCheck permet d'utiliser [[@LIGNE]], [[@LINE+ ]],
[[@LIGNE- ]] expressions dans les motifs. Ces expressions s'étendent à un certain nombre de
ligne où se trouve un motif (avec un décalage entier facultatif).

De cette façon, les motifs de correspondance peuvent être placés près des lignes de test pertinentes et inclure la ligne relative
références numériques, par exemple :

// VÉRIFIER : test.cpp:[[@LINE+4]]:6 : erreur : ';' attendu après le déclarant de premier niveau
// CHECK-NEXT : {{^int a}}
// CHECK-NEXT : {{^ \^}}
// CHECK-NEXT : {{^ ;}}
un

Utilisez FileCheck-3.6 en ligne à l'aide des services onworks.net