FileCheck-3.6 - Online sa Cloud

PROGRAMA:

NAME

FileCheck - Flexible na pattern na tumutugma sa file verifier

SINOPSIS

FileCheck tugma-filename [--check-prefix=XXX] [--strict-whitespace]

DESCRIPTION

FileCheck nagbabasa ng dalawang file (isa mula sa karaniwang input, at isa na tinukoy sa command line)
at ginagamit ang isa para i-verify ang isa pa. Ang pag-uugaling ito ay partikular na kapaki-pakinabang para sa testsuite,
na gustong i-verify na ang output ng ilang tool (hal llc) naglalaman ng inaasahan
impormasyon (halimbawa, isang movsd mula sa esp o anumang kawili-wili). Ito ay katulad
na gamit grep, ngunit ito ay na-optimize para sa pagtutugma ng maraming iba't ibang mga input sa isang file sa a
tiyak na pagkakasunud-sunod.

Ang tugma-filename file ay tumutukoy sa file na naglalaman ng mga pattern upang tumugma. Ang file
to verify ay binabasa mula sa karaniwang input maliban kung ang --input-file ginagamit ang opsyon.

Opsyon

-tulong Mag-print ng buod ng mga opsyon sa command line.

--check-prefix unlapi
Hinahanap ng FileCheck ang mga nilalaman ng tugma-filename para magkatugma ang mga pattern. Sa pamamagitan ng
default, ang mga pattern na ito ay may prefix na "Suriin:". Kung gusto mong gumamit ng a
magkaibang prefix (hal. dahil ang parehong input file ay nagsusuri ng maramihang iba
tool o mga opsyon), ang --check-prefix pinapayagan ka ng argumento na tukuyin ang isa o higit pa
mga prefix upang tumugma. Ang maraming prefix ay kapaki-pakinabang para sa mga pagsubok na maaaring magbago para sa
iba't ibang mga opsyon sa pagtakbo, ngunit ang karamihan sa mga linya ay nananatiling pareho.

--input-file filename
File na susuriin (default sa stdin).

--strict-whitespace
Bilang default, i-canonicalize ng FileCheck ang input horizontal whitespace (mga puwang at tab)
na nagiging sanhi upang balewalain ang mga pagkakaibang ito (tutugma ang isang puwang sa isang tab). Ang
--strict-whitespace hindi pinapagana ng argumento ang pag-uugaling ito. Ang mga end-of-line na sequence ay
canonicalized sa UNIX-style \n sa lahat ng mga mode.

--implicit-check-not check-pattern
Nagdaragdag ng mga implicit na negatibong pagsusuri para sa mga tinukoy na pattern sa pagitan ng mga positibong pagsusuri.
Ang opsyon ay nagbibigay-daan sa pagsulat ng mas mahigpit na mga pagsubok nang hindi pinupuno ang mga ito CHECK-HINDIs.

Halimbawa, "--implicit-check-not babala:" ay maaaring maging kapaki-pakinabang kapag sumusubok sa diagnostic
mga mensahe mula sa mga tool na walang opsyong katulad ng clang -patunayan. Kasama nito
Ang opsyon na FileCheck ay magpapatunay na ang input ay hindi naglalaman ng mga babala na hindi sakop ng
anumang Suriin: mga pattern.

-version
Ipakita ang numero ng bersyon ng program na ito.

EXIT STATUS

If FileCheck nagpapatunay na ang file ay tumutugma sa inaasahang nilalaman, ito ay lalabas na may 0.
Kung hindi, kung hindi, o kung may naganap na error, lalabas ito nang may hindi zero na halaga.

PAGTUTURO

Karaniwang ginagamit ang FileCheck mula sa mga pagsubok sa pagbabalik ng LLVM, na hinihingi sa linya ng RUN ng
ang pagsubok. Ang isang simpleng halimbawa ng paggamit ng FileCheck mula sa isang RUN line ay ganito ang hitsura:

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

Sinasabi ng syntax na ito na i-pipe ang kasalukuyang file ("%s") sa llvm-as, pipe na sa llc, Pagkatapos
pipe ang output ng llc sa FileCheck. Nangangahulugan ito na ang FileCheck ay magpapatunay nito
standard input (ang llc output) laban sa filename argument na tinukoy (ang orihinal .ll
file na tinukoy ng "%s"). Para makita kung paano ito gumagana, tingnan natin ang iba pa .ll file
(pagkatapos ng linya ng RUN):

tukuyin ang void @sub1(i32* %p, i32 %v) {
entry:
; SURIIN: sub1:
; CHECK: subl
%0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
ret void
}

tukuyin ang void @inc4(i64* %p) {
entry:
; SURIIN: inc4:
; CHECK: incq
%0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
ret void
}

Dito mo makikita ang ilan"Suriin:" mga linyang tinukoy sa mga komento. Ngayon ay makikita mo kung paano ang file
ay pinapasok sa llvm-as, Pagkatapos llc, at ang output ng machine code ay ang aming bini-verify.
Sinusuri ng FileCheck ang output ng machine code upang i-verify na tumutugma ito sa kung ano ang "Suriin:"mga linya
tukuyin.

Ang syntax ng "Suriin:"Ang mga linya ay napaka-simple: ang mga ito ay mga nakapirming string na dapat mangyari sa
utos. Nagde-default ang FileCheck sa pagbalewala sa mga pahalang na whitespace na pagkakaiba (hal
pinapayagang tumugma sa isang tab) ngunit kung hindi, ang mga nilalaman ng "Suriin:"kinakailangan ang linya para
eksaktong tumugma sa ilang bagay sa test file.

Ang isang magandang bagay tungkol sa FileCheck (kumpara sa grep) ay pinapayagan nitong pagsamahin ang mga kaso ng pagsubok
magkasama sa mga lohikal na grupo. Halimbawa, dahil sinusuri ng pagsubok sa itaas ang
"sub1:"At"inc4:" mga label, hindi ito tutugma maliban kung mayroong "subl"sa pagitan ng mga iyon
mga label. Kung umiral ito sa ibang lugar sa file, hindi iyon mabibilang: "grep subl"
tumutugma kung "subl" ay umiiral kahit saan sa file.

Ang FileCheck -check-prefix opsyon
Ang FileCheck -check-prefix ang opsyon ay nagbibigay-daan sa maramihang mga pagsasaayos ng pagsubok na maihatid mula sa
isa .ll file. Ito ay kapaki-pakinabang sa maraming pagkakataon, halimbawa, iba't ibang pagsubok
mga variant ng arkitektura na may llc. Narito ang isang simpleng halimbawa:

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

tukuyin ang <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: pinsrd_1:
; X32: pinsrd $1, 4(%esp), %xmm0

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

Sa kasong ito, sinusubukan namin na makuha namin ang inaasahang pagbuo ng code na may parehong 32-bit at
64-bit na pagbuo ng code.

Ang CHECK-NEXT: direktiba
Minsan gusto mong itugma ang mga linya at gusto mong i-verify na eksaktong nangyayari ang mga tugma
magkasunod na linya na walang ibang linya sa pagitan nila. Sa kasong ito, maaari mong gamitin ang "Suriin:"
at "CHECK-NEXT:" direktiba upang tukuyin ito. Kung tinukoy mo ang isang pasadyang prefix ng tseke,
gamitin mo lang"-SUSUNOD:". Halimbawa, ang isang bagay na tulad nito ay gumagana tulad ng iyong inaasahan:

define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
%tmp3 = load <2 x double>* %A, align 16
%tmp7 = insertelement <2 x double> undef, double %B, i32 0
%tmp9 = shufflevector <2 x double> %tmp3,
<2 x doble> %tmp7,
<2 x i32> < i32 0, i32 2 >
mag-imbak <2 x double> %tmp9, <2 x double>* %r, ihanay 16
ret void

; SURIIN: t2:
; SURIIN: 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:" tinatanggihan ng mga direktiba ang input maliban kung may eksaktong isang bagong linya sa pagitan nito
at ang naunang direktiba. A"CHECK-NEXT:" hindi maaaring ang unang direktiba sa isang file.

Ang CHECK-NOT: direktiba
Ang "CHECK-NOT:Ang " direktiba ay ginagamit upang i-verify na ang isang string ay hindi nangyayari sa pagitan ng dalawa
mga laban (o bago ang unang laban, o pagkatapos ng huling laban). Halimbawa, para ma-verify iyon
ang isang load ay tinanggal sa pamamagitan ng isang pagbabagong-anyo, ang isang pagsubok na tulad nito ay maaaring gamitin:

tukuyin ang i8 @coerce_offset0(i32 %V, i32* %P) {
mag-imbak ng i32 %V, i32* %P

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

%A = load i8* %P3
ret i8 %A
; SURIIN: @coerce_offset0
; CHECK-NOT: load
; SURIIN: ret i8
}

Ang CHECK-DAG: direktiba
Kung kinakailangan upang tumugma sa mga string na hindi nangyayari sa isang mahigpit na pagkakasunud-sunod,
"CHECK-DAG:" ay maaaring gamitin upang i-verify ang mga ito sa pagitan ng dalawang laban (o bago ang unang laban,
o pagkatapos ng huling laban). Halimbawa, ang clang ay nagpapalabas ng mga vtable na global sa reverse order. Gamit
CHECK-DAG:, maaari naming panatilihin ang mga tseke sa natural na pagkakasunud-sunod:

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

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

struct Bar { virtual void method(); };
Bar b;
// CHECK-DAG: @_ZTV3Bar =

CHECK-NOT: maaaring ihalo ang mga direktiba sa CHECK-DAG: mga direktiba upang ibukod ang mga string sa pagitan
ang nakapaligid CHECK-DAG: mga direktiba. Bilang resulta, ang paligid CHECK-DAG: direktiba
hindi maaaring muling ayusin, ibig sabihin, lahat ng mga pangyayari ay tumutugma CHECK-DAG: bago CHECK-NOT: hindi dapat
nasa likod ng mga pagtutugma ng mga pangyayari CHECK-DAG: pagkatapos CHECK-NOT:. Halimbawa,

; CHECK-DAG: NOON
; CHECK-NOT: HINDI
; CHECK-DAG: PAGKATAPOS

Tatanggihan ng kasong ito ang mga string ng input kung saan BAGO nangyayari pagkatapos PAGKATAPOS.

Sa mga nakuhang variable, CHECK-DAG: ay kayang tumugma sa wastong topological na mga order ng isang DAG
na may mga gilid mula sa kahulugan ng isang variable hanggang sa paggamit nito. Ito ay kapaki-pakinabang, hal, kapag ang iyong
Ang mga kaso ng pagsubok ay kailangang tumugma sa iba't ibang mga sequence ng output mula sa scheduler ng pagtuturo. Para sa
Halimbawa,

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

Sa kasong ito, anumang pagkakasunud-sunod ng dalawang iyon idagdag papayagan ang mga tagubilin.

Kung ikaw ay tumutukoy at gamit ang mga variable sa pareho CHECK-DAG: block, magkaroon ng kamalayan na ang
maaaring tumugma ang panuntunan sa kahulugan pagkatapos paggamit nito.

Kaya, halimbawa, ang code sa ibaba ay ipapasa:

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

Habang ang ibang code na ito, ay hindi:

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

Bagama't maaari itong maging lubhang kapaki-pakinabang, mapanganib din ito, dahil sa kaso ng pagpaparehistro
pagkakasunud-sunod, dapat kang magkaroon ng isang malakas na pagkakasunud-sunod (basahin bago magsulat, kopyahin bago gamitin, atbp). Kung ang
kahulugan na hinahanap ng iyong pagsubok ay hindi tumutugma (dahil sa isang bug sa compiler), ito
maaaring tumugma sa mas malayo sa paggamit, at itago ang mga totoong bug.

Sa mga kasong iyon, para ipatupad ang utos, gumamit ng di-DAG na direktiba sa pagitan ng mga DAG-block.

Ang CHECK-LABEL: direktiba
Minsan sa isang file na naglalaman ng maraming pagsubok na nahahati sa mga lohikal na bloke, isa o higit pa
Suriin: ang mga direktiba ay maaaring hindi sinasadyang magtagumpay sa pamamagitan ng pagtutugma ng mga linya sa susunod na bloke. Habang ang isang
ang error ay kadalasang bubuo sa kalaunan, ang tseke na na-flag bilang sanhi ng error ay maaaring hindi
aktwal na nagdadala ng anumang kaugnayan sa aktwal na pinagmulan ng problema.

Upang makagawa ng mas mahusay na mga mensahe ng error sa mga kasong ito, ang "CHECK-LABEL:"maaari ang direktiba
gamitin. Ito ay ginagamot nang pareho sa isang normal CHECK direktiba maliban sa FileCheck na gumagawa
isang karagdagang pagpapalagay na ang isang linya na tumugma sa direktiba ay hindi rin maaaring tumugma ng
anumang iba pang check in tugma-filename; ito ay inilaan upang gamitin para sa mga linya
naglalaman ng mga label o iba pang natatanging identifier. Conceptually, ang presensya ng CHECK-LABEL
hinahati ang input stream sa magkakahiwalay na mga bloke, na ang bawat isa ay pinoproseso nang nakapag-iisa,
pagpigil a Suriin: direktiba sa isang bloke na tumutugma sa isang linya sa isa pang bloke. Halimbawa,

tukuyin ang %struct.C* @C_ctor_base(%struct.C* %ito, i32 %x) {
entry:
; CHECK-LABEL: C_ctor_base:
; CHECK: mov [[SAVETHIS:r[0-9]+]], r0
; SURIIN: bl A_ctor_base
; SURIIN: mov r0, [[SAVETHIS]]
%0 = bitcast %struct.C* %ito sa %struct.A*
%call = tail call %struct.A* @A_ctor_base(%struct.A* %0)
%1 = bitcast %struct.C* %ito sa %struct.B*
%call2 = tail call %struct.B* @B_ctor_base(%struct.B* %1, i32 %x)
ret %struct.C* %ito
}

tukuyin ang %struct.D* @D_ctor_base(%struct.D* %ito, i32 %x) {
entry:
; CHECK-LABEL: D_ctor_base:

Ang paggamit ng CHECK-LABEL: ang mga direktiba sa kasong ito ay tumitiyak na ang tatlo Suriin: direktiba
tumanggap lamang ng mga linyang naaayon sa katawan ng @C_ctor_base function, kahit na ang
tumutugma ang mga pattern sa mga linyang makikita sa ibang pagkakataon sa file. Higit pa rito, kung isa sa tatlong ito Suriin:
nabigo ang mga direktiba, mababawi ang FileCheck sa pamamagitan ng pagpapatuloy sa susunod na bloke, na nagpapahintulot sa maramihang
mga pagkabigo sa pagsubok na matutukoy sa iisang invocation.

Walang kinakailangan na CHECK-LABEL: ang mga direktiba ay naglalaman ng mga string na tumutugma sa
aktwal na syntactic na mga label sa isang source o output na wika: dapat silang natatanging tumugma sa a
isang linya sa file na bini-verify.

CHECK-LABEL: ang mga direktiba ay hindi maaaring maglaman ng mga variable na kahulugan o gamit.

FileCheck huwaran Pagtutugma palaugnayan
Ang "Suriin:"At"CHECK-NOT:" ang mga direktiba ay parehong kumukuha ng pattern upang tumugma. Para sa karamihan ng paggamit ng
FileCheck, ang fixed string matching ay ganap na sapat. Para sa ilang bagay, higit pa
flexible form ng pagtutugma ay ninanais. Upang suportahan ito, pinapayagan ka ng FileCheck na tukuyin
mga regular na expression sa pagtutugma ng mga string, na napapalibutan ng double braces: {{yourregex}}.
Dahil gusto naming gumamit ng nakapirming pagtutugma ng string para sa karamihan ng ginagawa namin, mayroon ang FileCheck
idinisenyo upang suportahan ang paghahalo at pagtutugma ng nakapirming pagtutugma ng string sa regular
mga ekspresyon. Pinapayagan ka nitong magsulat ng mga bagay tulad nito:

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

Sa kasong ito, papayagan ang anumang offset mula sa rehistro ng ESP, at papayagan ang anumang rehistro ng xmm
payagan.

Dahil ang mga regular na expression ay may kasamang double braces, ang mga ito ay nakikitang naiiba,
at hindi mo kailangang gumamit ng mga escape character sa loob ng double braces tulad ng gagawin mo sa C.
Sa bihirang kaso na gusto mong itugma ang double braces nang tahasan mula sa input, magagawa mo
gumamit ng pangit na parang {{[{][{]}} bilang iyong pattern.

FileCheck Variable
Madalas na kapaki-pakinabang na tumugma sa isang pattern at pagkatapos ay i-verify na ito ay nangyayari muli sa ibang pagkakataon sa
file. Para sa mga pagsubok sa codegen, maaari itong maging kapaki-pakinabang upang payagan ang anumang rehistro, ngunit i-verify iyon
Ang rehistro ay patuloy na ginagamit sa ibang pagkakataon. Na gawin ito, FileCheck nagbibigay-daan sa mga pinangalanang variable na maging
tinukoy at pinalitan sa mga pattern. Narito ang isang simpleng halimbawa:

; SURIIN: pagsubok5:
; SURIIN: ngayon [[REGISTER:%[az]+]]
; SURIIN: at {{.*}}[[REGISTER]]

Ang unang check line ay tumutugma sa isang regex %[az]+ at kinukuha ito sa variable REGISTER.
Ang pangalawang linya ay nagpapatunay na kung ano ang nasa REGISTER nangyayari mamaya sa file pagkatapos ng isang
"at w". FileCheck ang mga variable na sanggunian ay palaging nakapaloob sa [[ ]] pares, at kanilang
maaaring mabuo ang mga pangalan gamit ang regex [a-zA-Z][a-zA-Z0-9]*. Kung ang isang tutuldok ay sumusunod sa pangalan,
pagkatapos ito ay isang kahulugan ng variable; kung hindi, ito ay isang gamit.

FileCheck Ang mga variable ay maaaring tukuyin nang maraming beses, at ang mga gamit ay palaging nakakakuha ng pinakabagong halaga.
Magagamit din ang mga variable sa ibang pagkakataon sa parehong linya kung saan sila tinukoy. Halimbawa:

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

Maaaring maging kapaki-pakinabang kung gusto mo ang mga operand ng op upang maging parehong rehistro, at walang pakialam
eksakto kung aling rehistro ito.

FileCheck expression
Minsan may pangangailangang i-verify ang output na tumutukoy sa mga numero ng linya ng file ng tugma,
hal kapag sinusubukan ang mga diagnostic ng compiler. Ito ay nagpapakilala ng isang tiyak na hina ng laban
istraktura ng file, bilang "Suriin:" ang mga linya ay naglalaman ng ganap na mga numero ng linya sa parehong file, na
kailangang ma-update sa tuwing nagbabago ang mga numero ng linya dahil sa pagdaragdag o pagtanggal ng teksto.

Upang suportahan ang kasong ito, pinapayagan ng FileCheck ang paggamit [[@LINE]], [[@LINE+ ]],
[[@LINE- ]] mga expression sa mga pattern. Ang mga ekspresyong ito ay lumalawak sa isang bilang ng
linya kung saan matatagpuan ang isang pattern (na may opsyonal na integer offset).

Sa ganitong paraan maaaring ilagay ang mga pattern ng pagtutugma malapit sa mga nauugnay na linya ng pagsubok at isama ang kamag-anak na linya
mga sanggunian sa numero, halimbawa:

// CHECK: test.cpp:[[@LINE+4]]:6: error: expected ';' pagkatapos ng pinakamataas na antas ng deklarador
// CHECK-NEXT: {{^int a}}
// CHECK-NEXT: {{^ \^}}
// CHECK-NEXT: {{^ ;}}
int a

Gamitin ang FileCheck-3.6 online gamit ang mga serbisyo ng onworks.net