FileCheck-3.6: en línea en la nube

PROGRAMA:

NOMBRE

FileCheck: verificador de archivos de coincidencia de patrones flexible

SINOPSIS

Chequeo de archivo coincidencia de nombre de archivo [--check-prefix = XXX] [--estricto-espacio en blanco]

DESCRIPCIÓN

Chequeo de archivo lee dos archivos (uno de la entrada estándar y otro especificado en la línea de comando)
y usa uno para verificar el otro. Este comportamiento es particularmente útil para el conjunto de pruebas,
que quiere verificar que la salida de alguna herramienta (p. ej. LLC) contiene lo esperado
información (por ejemplo, un movsd de esp o lo que sea interesante). Esto es similar
a la utilización de grep, pero está optimizado para hacer coincidir múltiples entradas diferentes en un archivo en un
orden específica.

El coincidencia de nombre de archivo archivo especifica el archivo que contiene los patrones para hacer coincidir. El archivo
verificar se lee de la entrada estándar a menos que el --fichero de entrada se utiliza la opción.

CAMPUS

-ayuda Imprima un resumen de las opciones de la línea de comandos.

--check-prefijo prefijo
FileCheck busca el contenido de coincidencia de nombre de archivo para que los patrones coincidan. Por
por defecto, estos patrones tienen el prefijo "REVISIÓN:". Si desea utilizar un
prefijo diferente (por ejemplo, porque el mismo archivo de entrada está comprobando múltiples
herramienta u opciones), la --check-prefijo argumento le permite especificar uno o más
prefijos para que coincidan. Múltiples prefijos son útiles para pruebas que pueden cambiar para
diferentes opciones de ejecución, pero la mayoría de las líneas siguen siendo las mismas.

--fichero de entrada nombre de archivo
Archivo para comprobar (predeterminado en stdin).

--estricto-espacio en blanco
De forma predeterminada, FileCheck canonicaliza los espacios en blanco horizontales de entrada (espacios y tabulaciones)
lo que hace que ignore estas diferencias (un espacio coincidirá con una pestaña). los
--estricto-espacio en blanco El argumento desactiva este comportamiento. Las secuencias de fin de línea son
canonicalizado al estilo UNIX \n en todos los modos.

--implícito-comprobar-no patrón de verificación
Agrega verificaciones negativas implícitas para los patrones especificados entre verificaciones positivas.
La opción permite escribir pruebas más estrictas sin rellenarlas con VERIFICAR NOs.

Por ejemplo, "--implícito-comprobar-no advertencia:"puede ser útil al realizar pruebas de diagnóstico
mensajes de herramientas que no tienen una opción similar a sonido metálico -verificar. Con este
La opción FileCheck verificará que la entrada no contenga advertencias no cubiertas por
cualquier REVISIÓN: .

-versión
Muestra el número de versión de este programa.

SALIR ESTADO

If Chequeo de archivo verifica que el archivo coincide con el contenido esperado, sale con 0.
De lo contrario, si no, o si ocurre un error, saldrá con un valor distinto de cero.

TUTORIAL

FileCheck se utiliza normalmente a partir de pruebas de regresión LLVM, y se invoca en la línea RUN de
la prueba. Un ejemplo simple del uso de FileCheck desde una línea RUN se ve así:

; EJECUTAR: llvm-as <% s | llc -march = x86-64 | FileCheck% s

Esta sintaxis dice que canalice el archivo actual ("%s") en llvm-as, canaliza eso en LLC, entonces
canalizar la salida de LLC dentro Chequeo de archivo. Esto significa que FileCheck verificará su
entrada estándar (la salida llc) contra el argumento de nombre de archivo especificado (el original .ll
archivo especificado por "%s"). Para ver cómo funciona, veamos el resto de .ll presentar
(después de la línea RUN):

define void @ sub1 (i32 *% p, i32% v) {
entrada:
; COMPROBAR: sub1:
; COMPROBAR: subl
% 0 = llamada final i32 @ llvm.atomic.load.sub.i32.p0i32 (i32 *% p, i32% v)
ret vacío
}

define void @ inc4 (i64 *% p) {
entrada:
; COMPROBAR: inc4:
; COMPROBAR: incq
% 0 = llamada final i64 @ llvm.atomic.load.add.i64.p0i64 (i64 *% p, i64 1)
ret vacío
}

Aquí puedes ver algunos "REVISIÓN:"líneas especificadas en los comentarios. Ahora puede ver cómo el archivo
se canaliza en llvm-as, entonces LLC, y la salida del código de máquina es lo que estamos verificando.
FileCheck comprueba la salida del código de máquina para verificar que coincida con lo que "REVISIÓN:" líneas
especificar.

La sintaxis de "REVISIÓN:"líneas es muy simple: son cadenas fijas que deben ocurrir en
pedido. FileCheck por defecto ignora las diferencias de espacios en blanco horizontales (por ejemplo, un espacio es
permitir que coincida con una pestaña) pero, de lo contrario, el contenido de la "REVISIÓN:"Se requiere línea para
coincidir con algo en el archivo de prueba exactamente.

Una cosa buena de FileCheck (en comparación con grep) es que permite fusionar casos de prueba
juntos en grupos lógicos. Por ejemplo, debido a que la prueba anterior verifica la
"sub1:"Y"Inc4:"etiquetas, no coincidirá a menos que haya un"sublime"entre esos
etiquetas. Si existiera en algún otro lugar del archivo, eso no contaría: "grep sublime"
coincide con si "sublime"existe en cualquier parte del archivo.

El Chequeo de archivo -prefijo de verificación opción
El FileCheck -prefijo de verificación La opción permite controlar múltiples configuraciones de prueba desde
una .ll expediente. Esto es útil en muchas circunstancias, por ejemplo, probar diferentes
variantes arquitectónicas con LLC. He aquí un ejemplo sencillo:

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

define <4 x i32> @ pinsrd_1 (i32% s, <4 x i32>% tmp) nounwind {
% tmp1 = insertelemento <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
}

En este caso, estamos probando que obtengamos la generación de código esperada con 32 bits y
Generación de código de 64 bits.

El VERIFICAR SIGUIENTE: Directivas
A veces desea hacer coincidir líneas y le gustaría verificar que las coincidencias sucedan exactamente
líneas consecutivas sin otras líneas entre ellas. En este caso, puede utilizar "REVISIÓN:"
y "VERIFICAR SIGUIENTE:"directivas para especificar esto. Si especificó un prefijo de verificación personalizado,
Solo usa "-SIGUIENTE:". Por ejemplo, algo como esto funciona como era de esperar:

define void @ t2 (<2 x doble> *% r, <2 x doble> *% A, doble% B) {
% tmp3 = cargar <2 x doble> *% A, alinear 16
% tmp7 = insertelement <2 x double> undef, double% B, i32 0
% tmp9 = shufflevector <2 x doble>% tmp3,
<2 x doble>% tmp7,
<2 x i32> <i32 0, i32 2>
almacenar <2 x doble>% tmp9, <2 x doble> *% r, alinear 16
ret vacío

; COMPROBAR: t2:
; COMPROBAR: movl 8 (% esp),% eax
; COMPROBAR SIGUIENTE: movapd (% eax),% xmm0
; COMPROBAR SIGUIENTE: movhpd 12 (% esp),% xmm0
; COMPROBAR SIGUIENTE: movl 4 (% esp),% eax
; COMPROBAR SIGUIENTE: movapd% xmm0, (% eax)
; COMPROBAR SIGUIENTE: ret
}

"VERIFICAR SIGUIENTE:"Las directivas rechazan la entrada a menos que haya exactamente una nueva línea entre ellas
y la directiva anterior. A "VERIFICAR SIGUIENTE:"no puede ser la primera directiva de un archivo.

El NO COMPROBAR: Directivas
La "NO COMPROBAR:"La directiva se utiliza para verificar que no se produzca una cadena entre dos
partidos (o antes del primer partido o después del último partido). Por ejemplo, para verificar que
una carga se elimina mediante una transformación, se puede utilizar una prueba como esta:

definir i8 @ coerce_offset0 (i32% V, i32 *% P) {
almacenar i32% V, i32 *% P

% P2 = transmisión de bits de i32 *% P a i8 *
% P3 = getelementptr i8 *% P2, i32 2

% A = carga i8 *% P3
ret i8% A
; VERIFICAR: @ ​​coerce_offset0
; NO COMPROBAR: cargar
; COMPROBAR: ret i8
}

El CHEQUE-DAG: Directivas
Si es necesario hacer coincidir cadenas que no ocurren en un orden estrictamente secuencial,
"CHEQUE-DAG:"podría utilizarse para verificarlos entre dos partidos (o antes del primer partido,
o después del último partido). Por ejemplo, clang emite vtable globales en orden inverso. Utilizando
CHEQUE-DAG:, podemos mantener los cheques en el orden natural:

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

struct Foo {método vacío virtual (); };
Foo f; // emitir vtable
// CHECK-DAG: @ _ZTV3Foo =

struct Bar {método de vacío virtual (); };
barra b;
// CHECK-DAG: @ _ZTV3Bar =

NO COMPROBAR: las directivas se pueden mezclar con CHEQUE-DAG: directivas para excluir cadenas entre
El alrededor CHEQUE-DAG: directivas. Como resultado, los alrededores CHEQUE-DAG: directivas
no se puede reordenar, es decir, todas las ocurrencias coinciden CHEQUE-DAG: antes NO COMPROBAR: no debe
quedarse atrás coincidencia de ocurrencias CHEQUE-DAG: después de NO COMPROBAR:. Por ejemplo,

; CHECK-DAG: ANTES
; NO COMPROBAR: NO
; CHECK-DAG: DESPUÉS

Este caso rechazará las cadenas de entrada donde ANTES ocurre después DESPUÉS DE .

Con variables capturadas, CHEQUE-DAG: es capaz de hacer coincidir los ordenamientos topológicos válidos de un DAG
con aristas desde la definición de una variable hasta su uso. Es útil, por ejemplo, cuando su
los casos de prueba deben coincidir con diferentes secuencias de salida del programador de instrucciones. Para
ejemplo,

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

En este caso, cualquier orden de esos dos add Se permitirán instrucciones.

Si estas definiendo y usando variables en el mismo CHEQUE-DAG: bloque, tenga en cuenta que el
la regla de definición puede coincidir después de su uso.

Entonces, por ejemplo, el siguiente código pasará:

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

Mientras que este otro código, no:

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

Si bien esto puede ser muy útil, también es peligroso, porque en el caso del registro
secuencia, debe tener un orden fuerte (leer antes de escribir, copiar antes de usar, etc.). Si el
La definición que busca su prueba no coincide (debido a un error en el compilador),
puede coincidir más lejos del uso y enmascarar errores reales.

En esos casos, para hacer cumplir la orden, use una directiva que no sea DAG entre bloques DAG.

El ETIQUETA DE VERIFICACIÓN: Directivas
A veces, en un archivo que contiene varias pruebas divididas en bloques lógicos, uno o más
REVISIÓN: las directivas pueden tener éxito inadvertidamente al hacer coincidir líneas en un bloque posterior. Mientras un
El error generalmente se generará eventualmente, la verificación marcada como causante del error puede no
realmente guardan alguna relación con la fuente real del problema.

Para producir mejores mensajes de error en estos casos, el "ETIQUETA DE VERIFICACIÓN:"directiva puede
ser usado. Se trata de forma idéntica a una normal. CHEQUE directiva excepto que FileCheck hace
una suposición adicional de que una línea igualada por la directiva no puede ser igualada también por
cualquier otro cheque presente en coincidencia de nombre de archivo; esto está destinado a ser utilizado para líneas
que contiene etiquetas u otros identificadores únicos. Conceptualmente, la presencia de ETIQUETA DE VERIFICACIÓN
divide el flujo de entrada en bloques separados, cada uno de los cuales se procesa de forma independiente,
previniendo un REVISIÓN: directiva en un bloque que coincide con una línea en otro bloque. Por ejemplo,

define% struct.C * @C_ctor_base (% struct.C *% this, i32% x) {
entrada:
; ETIQUETA DE VERIFICACIÓN: C_ctor_base:
; COMPROBAR: mov [[GUARDAR ESTO: r [0-9] +]], r0
; COMPROBAR: bl A_ctor_base
; VERIFICAR: mov r0, [[GUARDAR]]
% 0 = bitcast% struct.C *% esto a% struct.A *
% call = tail call% struct.A * @A_ctor_base (% struct.A *% 0)
% 1 = bitcast% struct.C *% esto a% struct.B *
% call2 = cola de llamada% struct.B * @B_ctor_base (% struct.B *% 1, i32% x)
ret% estructura. C *% esto
}

define% struct.D * @D_ctor_base (% struct.D *% this, i32% x) {
entrada:
; ETIQUETA DE VERIFICACIÓN: D_ctor_base:

El uso de ETIQUETA DE VERIFICACIÓN: directivas en este caso asegura que las tres REVISIÓN: directivas
Solo acepta líneas correspondientes al cuerpo del @C_ctor_base función, incluso si el
los patrones coinciden con las líneas que se encuentran más adelante en el archivo. Además, si uno de estos tres REVISIÓN:
directivas fallan, FileCheck se recuperará al continuar con el siguiente bloque, permitiendo múltiples
pruebas de fallas que se detectarán en una sola invocación.

No hay ningún requisito que ETIQUETA DE VERIFICACIÓN: Las directivas contienen cadenas que corresponden a
etiquetas sintácticas reales en un lenguaje fuente o de salida: simplemente deben coincidir unívocamente con un
línea única en el archivo que se está verificando.

ETIQUETA DE VERIFICACIÓN: las directivas no pueden contener definiciones o usos de variables.

Chequeo de archivo Patrón de Costura Coincidencia de Sintaxis
La "REVISIÓN:"Y"NO COMPROBAR:"Ambas directivas toman un patrón para coincidir. Para la mayoría de los usos de
FileCheck, la coincidencia de cadenas fijas es perfectamente suficiente. Para algunas cosas, más
se desea una forma flexible de emparejamiento. Para respaldar esto, FileCheck le permite especificar
expresiones regulares en cadenas coincidentes, rodeadas por llaves dobles: {{yourregex}}.
Debido a que queremos usar la coincidencia de cadenas fijas para la mayoría de lo que hacemos, FileCheck tiene
ha sido diseñado para admitir la mezcla y el emparejamiento de cuerdas fijas con regular
Expresiones Esto te permite escribir cosas como esta:

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

En este caso, se permitirá cualquier desplazamiento del registro ESP y cualquier registro xmm
ser permitido.

Dado que las expresiones regulares se incluyen entre llaves dobles, son visualmente distintas,
y no necesita usar caracteres de escape entre llaves dobles como lo haría en C.
En el raro caso de que desee hacer coincidir llaves dobles explícitamente de la entrada, puede
usa algo feo como {{[{][{]}} como su patrón.

Chequeo de archivo Variables
A menudo es útil hacer coincidir un patrón y luego verificar que vuelva a ocurrir más tarde en el
expediente. Para las pruebas de codegen, esto puede ser útil para permitir cualquier registro, pero verifique que
El registro se utiliza de forma coherente más tarde. Para hacer esto, Chequeo de archivo permite que las variables nombradas sean
definido y sustituido en patrones. A continuación, se muestra un ejemplo sencillo:

; COMPROBAR: test5:
; COMPROBAR: notw [[REGISTRO:% [az] +]]
; COMPROBAR: andw {{. *}} [[REGISTRARSE]]

La primera línea de verificación coincide con una expresión regular % [az] + y lo captura en la variable REGISTRO.
La segunda línea verifica que todo lo que esté en REGISTRO ocurre más adelante en el archivo después de una
"y W". Chequeo de archivo las referencias variables siempre están contenidas en [[ ]] parejas, y sus
los nombres se pueden formar con la expresión regular [a-zA-Z] [a-zA-Z0-9] *. Si dos puntos siguen al nombre,
entonces es una definición de la variable; de lo contrario, es un uso.

Chequeo de archivo las variables se pueden definir varias veces y los usos siempre obtienen el último valor.
Las variables también se pueden utilizar más adelante en la misma línea en la que se definieron. Por ejemplo:

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

Puede ser útil si desea los operandos de op ser el mismo registro, y no me importa
exactamente qué registro es.

Chequeo de archivo Expresiones
A veces es necesario verificar la salida que hace referencia a los números de línea del archivo de coincidencia,
por ejemplo, al probar los diagnósticos del compilador. Esto introduce una cierta fragilidad del partido.
estructura de archivo, como "REVISIÓN:"Las líneas contienen números de línea absolutos en el mismo archivo, que
deben actualizarse cada vez que los números de línea cambian debido a la adición o eliminación de texto.

Para respaldar este caso, FileCheck permite usar [[@LÍNEA]], [[@ LINE + ]],
[[@LÍNEA- ]] Expresiones en patrones. Estas expresiones se expanden a varios de los
línea donde se encuentra un patrón (con un desplazamiento de entero opcional).

De esta manera, los patrones de coincidencia se pueden colocar cerca de las líneas de prueba relevantes e incluir una línea relativa
referencias numéricas, por ejemplo:

// COMPROBAR: test.cpp: [[@ LINE + 4]]: 6: error: esperado ';' después del declarador de nivel superior
// VERIFICAR SIGUIENTE: {{^ int a}}
// VERIFICAR SIGUIENTE: {{^ \ ^}}
// VERIFICAR SIGUIENTE: {{^;}}
en un

Utilice FileCheck-3.6 en línea utilizando los servicios de onworks.net