Here what I want to match are the two llvm.memcpy instructions in
function test1 and test2.
If I don't place a dummy function between function test1 and test2,
the first llvm.memcpy won't
match even it indeed emitted (FileCheck says it cannot find the first
llvm.memcpy). However,
if I change to use CHECK instead of CHECK-LABEL, I don't need the
dummy function anymore,
and both llvm.memcpy get matched.
So my questions are:
1. when I use CHECK-LABEL, why the first llvm.memcpy cannot be
matched unless I add
a dummy function?
2. why the problem gone if I change to use CHECK?
3. after reading the document [1], I am still not sure when
CHECK-LABEL should/must be used.
could you exactly point it out?
CHECK-LABEL splits up the output into chunks before applying the rest
of the CHECKs. This has a couple of benefits for testing:
1. Used carefully you can make sure FileCheck is looking at the right
part of the output for the rest of your test (e.g. not in a completely
different function).
2. If there are multiple errors FileCheck will tell you about one of
them per block rather than just stopping at the first error in the
file.
1. when I use CHECK-LABEL, why the first llvm.memcpy cannot be
matched unless I add a dummy function?
We'd need to see the real .ll file to be sure. Typically this happens
because the CHECK-LABEL is picking up an earlier reference to its
string than the one you intend.
For example if @test1 called @test2 before doing its memcpy, the first
block would end at that call rather than at the definition of @test2.
You can probably fix this by including more context in the CHECK-LABEL
lines. Maybe something like "CHECK-LABEL: define void @test1".
2. why the problem gone if I change to use CHECK?
In that case the whole file is checked at once. The "CHECK: @test2"
line won't be picking up what you think it is, but there's still a
memcpy afterwards so it works.