[LLVMdev] Changes between 2.6 and 2.7: SSA Verifier and visitFreeInst

Jianzhou Zhao jianzhou at seas.upenn.edu
Mon Mar 8 17:03:25 PST 2010


On Sat, Mar 6, 2010 at 2:14 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Mar 6, 2010, at 9:13 AM, Jianzhou Zhao wrote:
>
>> Hi llvm,
>>
>> 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType,
>> which is empty in 2.6. I noticed that it does not check all types,
>> for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID
>> and etc are ignored in the 'default' branch. Does it mean we dont
>> need to check them?
>
> They are leaf types (just like integer type), there is nothing to check.
>
>> Another question is: How much does Verifier.cpp check statically?
>> Can I take it as a type checker for SSA? Is there any static
>> semantics that has not been checked yet?
>
> The verifier is best effort, it does not guarantee correctness.

Can we take the verifier as a reference to generate correct SSA?
I had some confusions when I was reading the RefManual
on the LLVM website, so I looked into the source code of
Verifier to see how well-formedness is checked in practice.

For example,
1) Can I have a block that does not start with a label?
Verifier checks that a block must end with a terminator
instruction. If the block without a label is not the entry block
in a function, could that be jumped into? or is it still a valid block?
since the syntax allows the label to be optional.

2) Verifier checks a block must contain only one terminator
insn which must be the last insn, and phi insns must be
in the beginning of the block as a group. If this is the right grammar,
could we not change the syntax of blocks as..?
  phi* i* t* where
    phi is a Phi node, i is an insn except Phi and terminator,
    and t is a terminator node.
So we dont need to check this at runtime.
This is same to ask if the verifier is a module that we have to run.

Thanks.

>
>> 2) visitFreeInst has been removed from lib/ExecutionEngine/Interpreter in 2.7
>> Will this have any back-compatible problem when interpreting any
>> *.bc from 2.6?
>
> The .bc reader will eliminate freeinst from the ir when reading an old file.
>
> -chris



-- 
Jianzhou



More information about the llvm-dev mailing list