FileCheck-3.6 - Online na nuvem

PROGRAMA:

NOME

FileCheck - verificador de arquivo de correspondência de padrão flexível

SINOPSE

Verificação de arquivo nome do arquivo correspondente [--check-prefix = XXX] [--strict-espaço em branco]

DESCRIÇÃO

Verificação de arquivo lê dois arquivos (um da entrada padrão e outro especificado na linha de comando)
e usa um para verificar o outro. Este comportamento é particularmente útil para a suíte de teste,
que deseja verificar se a saída de alguma ferramenta (por exemplo, llc) contém o esperado
informações (por exemplo, um movsd de esp ou o que for interessante). Isso é parecido
para usando grep, mas é otimizado para combinar várias entradas diferentes em um arquivo em um
pedido específico.

A nome do arquivo correspondente arquivo especifica o arquivo que contém os padrões correspondentes. O arquivo
para verificar se é lido da entrada padrão, a menos que o --Arquivo de entrada opção é usada.

OPÇÕES

-Socorro Imprima um resumo das opções da linha de comando.

--check-prefixo prefixo
FileCheck pesquisa o conteúdo de nome do arquivo correspondente para que os padrões correspondam. Por
padrão, esses padrões são prefixados com "VERIFICA:". Se você gostaria de usar um
prefixo diferente (por exemplo, porque o mesmo arquivo de entrada está verificando vários diferentes
ferramenta ou opções), o --check-prefixo argumento permite que você especifique um ou mais
prefixos correspondentes. Vários prefixos são úteis para testes que podem mudar para
opções de execução diferentes, mas a maioria das linhas permanece a mesma.

--Arquivo de entrada nome do arquivo
Arquivo a ser verificado (o padrão é stdin).

--strict-espaço em branco
Por padrão, FileCheck canoniza espaços em branco horizontais de entrada (espaços e tabulações)
o que faz com que ele ignore essas diferenças (um espaço corresponderá a uma guia). o
--strict-espaço em branco argumento desativa esse comportamento. As sequências de fim de linha são
canonizado para o estilo UNIX \n em todos os modos.

--implícito-check-not padrão de verificação
Adiciona verificações negativas implícitas para os padrões especificados entre verificações positivas.
A opção permite escrever testes mais rigorosos sem enchê-los de VERIFICAR-NÃOs.

Por exemplo, "--implícito-check-not Atenção:"pode ​​ser útil ao testar o diagnóstico
mensagens de ferramentas que não têm uma opção semelhante a retinir -verificar. Com isso
opção FileCheck irá verificar se a entrada não contém avisos não cobertos por
qualquer VERIFICA: padrões.

-versão
Mostra o número da versão deste programa.

SAIR STATUS

If Verificação de arquivo verifica se o arquivo corresponde ao conteúdo esperado e sai com 0.
Caso contrário, se não, ou se ocorrer um erro, ele sairá com um valor diferente de zero.

TUTORIAL

FileCheck é normalmente usado em testes de regressão LLVM, sendo invocado na linha RUN de
o teste. Um exemplo simples de uso de FileCheck de uma linha RUN se parece com isto:

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

Esta sintaxe diz para canalizar o arquivo atual ("%s") em llvm-as, canalize isso para llc, Em seguida
canalizar a saída de llc para dentro Verificação de arquivo. Isso significa que FileCheck verificará seu
entrada padrão (a saída llc) contra o argumento de nome de arquivo especificado (o original .ll
arquivo especificado por "%s"). Para ver como isso funciona, vamos dar uma olhada no resto do .ll lima
(após a linha RUN):

define void @ sub1 (i32 *% p, i32% v) {
entrada:
; VERIFICAR: sub1:
; VERIFICAR: subl
% 0 = chamada final i32 @ llvm.atomic.load.sub.i32.p0i32 (i32 *% p, i32% v)
ret nulo
}

define void @ inc4 (i64 *% p) {
entrada:
; VERIFICAR: inc4:
; VERIFICAR: incq
% 0 = chamada final i64 @ llvm.atomic.load.add.i64.p0i64 (i64 *% p, i64 1)
ret nulo
}

Aqui você pode ver alguns "VERIFICA:"linhas especificadas nos comentários. Agora você pode ver como o arquivo
é canalizado para llvm-as, Em seguida llc, e a saída do código de máquina é o que estamos verificando.
FileCheck verifica a saída do código de máquina para verificar se corresponde ao que o "VERIFICA:"linhas
especificamos.

A sintaxe do "VERIFICA:"linhas é muito simples: são strings fixas que devem ocorrer em
pedido. O padrão do FileCheck é ignorar as diferenças de espaço em branco horizontais (por exemplo, um espaço é
permitido corresponder a uma guia), mas caso contrário, o conteúdo do "VERIFICA:"linha é necessária para
coincidir com alguma coisa no arquivo de teste exatamente.

Uma coisa boa sobre FileCheck (em comparação com grep) é que ele permite mesclar casos de teste
juntos em grupos lógicos. Por exemplo, porque o teste acima está verificando o
"sub1:"E"inc4:"rótulos, ele não corresponderá a menos que haja um"sutil"entre aqueles
rótulos. Se existisse em outro lugar no arquivo, isso não contaria: "grep sutil"
corresponde se "sutil"existe em qualquer lugar do arquivo.

A Verificação de arquivo -prefixo de verificação opção
O FileCheck -prefixo de verificação opção permite que várias configurações de teste sejam conduzidas de
um .ll Arquivo. Isso é útil em muitas circunstâncias, por exemplo, testando diferentes
variantes arquitetônicas com llc. Aqui está um exemplo simples:

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

define <4 x i32> @ pinsrd_1 (i32% s, <4 x i32>% tmp) nounwind {
% tmp1 = insertelement <4 x i32>; % tmp, i32% s, i32 1
ret <4 x i32>% tmp1
; X32: pinosrd_1:
; X32: pinsrd $ 1, 4 (% esp),% xmm0

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

Neste caso, estamos testando se obtemos a geração de código esperada com 32 bits e
Geração de código de 64 bits.

A VERIFICAR-SEGUINTE: Directivas
Às vezes, você deseja combinar linhas e gostaria de verificar se as correspondências acontecem exatamente
linhas consecutivas sem outras linhas entre elas. Neste caso, você pode usar "VERIFICA:"
e "VERIFICAR-SEGUINTE:"para especificar isso. Se você especificou um prefixo de verificação personalizado,
Apenas use "-PRÓXIMO:". Por exemplo, algo assim funciona como você esperava:

define void @ t2 (<2 x double> *% r, <2 x double> *% A, double% B) {
% tmp3 = carregar <2 x duplo> *% A, alinhar 16
% tmp7 = insertelement <2 x double> undef, double% B, i32 0
% tmp9 = shufflevector <2 x double>% tmp3,
<2 x duplo>% tmp7,
<2 x i32> <i32 0, i32 2>
armazenar <2 x duplo>% tmp9, <2 x duplo> *% r, alinhar 16
ret nulo

; VERIFICAR: t2:
; VERIFICAR: 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)
; VERIFICAR PRÓXIMO: ret
}

"VERIFICAR-SEGUINTE:"as diretivas rejeitam a entrada, a menos que haja exatamente uma nova linha entre ela
e a diretiva anterior. UMA "VERIFICAR-SEGUINTE:"não pode ser a primeira diretiva em um arquivo.

A VERIFICAR-NÃO: Directivas
O "VERIFICAR-NÃO:"diretiva é usada para verificar se uma string não ocorre entre dois
partidas (ou antes da primeira partida, ou depois da última partida). Por exemplo, para verificar se
uma carga é removida por uma transformação, um teste como este pode ser usado:

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

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

% A = carga i8 *% P3
ret i8% A
; VERIFICAR: @ ​​coerce_offset0
; CHECK-NOT: carga
; VERIFICAR: ret i8
}

A CHECK-DAG: Directivas
Se for necessário combinar strings que não ocorrem em uma ordem estritamente sequencial,
"CHECK-DAG:"pode ​​ser usado para verificá-los entre duas partidas (ou antes da primeira partida,
ou após a última partida). Por exemplo, o clang emite vtable globais na ordem reversa. Usando
CHECK-DAG:, podemos manter as verificações na ordem natural:

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

struct Foo {método do vazio virtual (); };
Foo f; // emite vtable
// CHECK-DAG: @ _ZTV3Foo =

struct Bar {método do vazio virtual (); };
Barra b;
// CHECK-DAG: @ _ZTV3Bar =

VERIFICAR-NÃO: diretivas podem ser misturadas com CHECK-DAG: diretivas para excluir strings entre
o entorno CHECK-DAG: diretivas. Como resultado, o ambiente circundante CHECK-DAG: directivas
não pode ser reordenado, ou seja, todas as ocorrências correspondentes CHECK-DAG: antes VERIFICAR-NÃO: não deve
ficar para trás correspondência de ocorrências CHECK-DAG: depois de VERIFICAR-NÃO:. Por exemplo, a

; CHECK-DAG: ANTES
; VERIFICAR-NÃO: NÃO
; CHECK-DAG: APÓS

Este caso irá rejeitar strings de entrada onde ANTES ocorre depois APÓS.

Com variáveis ​​capturadas, CHECK-DAG: é capaz de corresponder a ordenações topológicas válidas de um DAG
com arestas desde a definição de uma variável até seu uso. É útil, por exemplo, quando seu
os casos de teste precisam corresponder a diferentes sequências de saída do agendador de instruções. Para
exemplo,

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

Neste caso, qualquer ordem desses dois adicionar instruções serão permitidas.

Se você está definindo e usando variáveis ​​no mesmo CHECK-DAG: bloco, esteja ciente de que o
regra de definição pode corresponder depois de seu uso.

Assim, por exemplo, o código abaixo passará:

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

Embora este outro código não:

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

Embora possa ser muito útil, também é perigoso, porque no caso de registro
seqüência, você deve ter uma ordem forte (ler antes de gravar, copiar antes de usar, etc). Se o
a definição que seu teste está procurando não corresponde (por causa de um bug no compilador),
pode combinar mais longe do uso e mascarar bugs reais.

Nesses casos, para fazer cumprir o pedido, use uma diretiva não DAG entre os blocos DAG.

A ETIQUETA DE VERIFICAÇÃO: Directivas
Às vezes, em um arquivo contendo vários testes divididos em blocos lógicos, um ou mais
VERIFICA: diretivas podem inadvertidamente ter sucesso combinando linhas em um bloco posterior. Enquanto um
o erro geralmente será gerado, a verificação sinalizada como causadora do erro pode não
na verdade, tenha qualquer relação com a origem real do problema.

Para produzir melhores mensagens de erro nesses casos, o "ETIQUETA DE VERIFICAÇÃO:"diretiva pode
ser usado. É tratado de forma idêntica a um normal VERIFICAÇÃO exceto que FileCheck torna
uma suposição adicional de que uma linha correspondida pela diretiva também não pode ser correspondida por
qualquer outro cheque presente em nome do arquivo correspondente; isto se destina a ser usado para linhas
contendo rótulos ou outros identificadores exclusivos. Conceitualmente, a presença de VERIFICAÇÃO DE ETIQUETA
divide o fluxo de entrada em blocos separados, cada um dos quais é processado de forma independente,
impedindo um VERIFICA: diretiva em um bloco correspondendo a uma linha em outro bloco. Por exemplo,

definir% struct.C * @C_ctor_base (% struct.C *% this, i32% x) {
entrada:
; CHECK-LABEL: C_ctor_base:
; VERIFICAR: mov [[SAVETHIS: r [0-9] +]], r0
; VERIFICAR: bl A_ctor_base
; VERIFICAR: mov r0, [[SAVETHIS]]
% 0 = bitcast% struct.C *% this to% struct.A *
% call = chamada final% struct.A * @A_ctor_base (% struct.A *% 0)
% 1 = bitcast% struct.C *% isto para% struct.B *
% call2 = chamada final% struct.B * @B_ctor_base (% struct.B *% 1, i32% x)
ret% struct.C *% this
}

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

O uso de ETIQUETA DE VERIFICAÇÃO: diretivas, neste caso, garante que os três VERIFICA: directivas
só aceita linhas correspondentes ao corpo do @C_ctor_base função, mesmo se o
os padrões correspondem às linhas encontradas posteriormente no arquivo. Além disso, se um desses três VERIFICA:
as diretivas falham, o FileCheck irá se recuperar continuando para o próximo bloco, permitindo vários
falhas de teste a serem detectadas em uma única invocação.

Não há nenhuma exigência de que ETIQUETA DE VERIFICAÇÃO: diretivas contêm strings que correspondem a
rótulos sintáticos reais em uma linguagem de origem ou de saída: eles devem simplesmente corresponder de forma única a um
linha única no arquivo que está sendo verificado.

ETIQUETA DE VERIFICAÇÃO: as diretivas não podem conter definições ou usos de variáveis.

Verificação de arquivo padrão Correspondente Sintaxe
O "VERIFICA:"E"VERIFICAR-NÃO:"ambas as diretivas usam um padrão para corresponder. Para a maioria dos usos de
FileCheck, a correspondência de string fixa é perfeitamente suficiente. Para algumas coisas, mais
forma flexível de correspondência é desejada. Para suportar isso, FileCheck permite que você especifique
expressões regulares em strings correspondentes, entre colchetes: {{yourregex}}.
Porque queremos usar correspondência de string fixa para a maioria do que fazemos, FileCheck tem
foi projetado para suportar a combinação e correspondência de cordas fixas com
expressões. Isso permite que você escreva coisas como:

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

Neste caso, qualquer deslocamento do registro ESP será permitido, e qualquer registro xmm será
ser permitido.

Como as expressões regulares são colocadas entre colchetes, elas são visualmente distintas,
e você não precisa usar caracteres de escape entre colchetes, como faria em C.
No caso raro em que você deseja combinar chaves duplas explicitamente a partir da entrada, você pode
use algo feio como {{[{][{]}} como seu padrão.

Verificação de arquivo Variáveis
Muitas vezes é útil combinar um padrão e, em seguida, verificar se ele ocorre novamente mais tarde no
Arquivo. Para testes codegen, isso pode ser útil para permitir qualquer registro, mas verifique se
registrar é usado consistentemente mais tarde. Para fazer isso, Verificação de arquivo permite que variáveis ​​nomeadas sejam
definido e substituído em padrões. Aqui está um exemplo simples:

; VERIFICAR: test5:
; VERIFICAR: notw [[REGISTRAR:% [az] +]]
; VERIFICAR: andw {{. *}} [[REGISTAR]]

A primeira linha de verificação corresponde a um regex % [az] + e captura na variável REGISTRE-SE!.
A segunda linha verifica se tudo o que está em REGISTRE-SE! ocorre posteriormente no arquivo, após um
"e W". Verificação de arquivo referências de variáveis ​​estão sempre contidas em [[ ]] pares, e seus
nomes podem ser formados com o regex [a-zA-Z] [a-zA-Z0-9] *. Se dois pontos vierem após o nome,
então é uma definição da variável; caso contrário, é um uso.

Verificação de arquivo as variáveis ​​podem ser definidas várias vezes e os usos sempre obtêm o valor mais recente.
As variáveis ​​também podem ser usadas posteriormente na mesma linha em que foram definidas. Por exemplo:

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

Pode ser útil se você quiser os operandos de op ser o mesmo cadastro, e não me importo
exatamente qual registro é.

Verificação de arquivo Expressões
Às vezes, é necessário verificar a saída que se refere aos números de linha do arquivo de correspondência,
por exemplo, ao testar os diagnósticos do compilador. Isso introduz uma certa fragilidade do jogo
estrutura de arquivo, como "VERIFICA:"linhas contêm números de linha absolutos no mesmo arquivo, que
devem ser atualizados sempre que os números das linhas mudam devido à adição ou exclusão de texto.

Para apoiar este caso, FileCheck permite usar [[@LINHA]], [[@ LINE + ]],
[[@LINHA- ]] expressões em padrões. Essas expressões se expandem para vários
linha onde um padrão está localizado (com um deslocamento de inteiro opcional).

Desta forma, os padrões de correspondência podem ser colocados perto das linhas de teste relevantes e incluem a linha relativa
referências numéricas, por exemplo:

// CHECK: test.cpp: [[@ LINE + 4]]: 6: erro: esperado ';' depois do declarador de nível superior
// VERIFICAR SEGUINTE: {{^ int a}}
// CHECK-NEXT: {{^ \ ^}}
// VERIFICAR SEGUINTE: {{^;}}
em um

Use FileCheck-3.6 online usando serviços onworks.net