[LLVMdev] About trapvalues

[Jianzhou Zhao]

Hi,

I am trying to understand trapvalues
  http://llvm.org/docs/LangRef.html#trapvalues
My question is that how LLVM expects to use trapvalues. Should we track if a
value is trapped or not at runtime or statically? One rule (for terminator
instruction) that defines a trap value is

  # An instruction control-depends on a terminator instruction if the
terminator instruction has multiple successors and the instruction is always
executed when control transfers to one of the successors, and may not be
executed when control is transfered to another.

But, at runtime, it seems difficult to know if an instruction "may not be
executed when control is transfered to another." For example of the code
given on the webpage.

entry:
  ...
  %br i1 %cmp, %true, %end ; Branch to either destination.

true:
   ...
   br label %end

end:
   ...
   volatile store i32 0, i32* @g ; %end is control-equivalent to %entry
                                            ; so this is defined (ignoring
earlier
                                            ; undefined behavior in this
example).

Statically, we can see the store in the end block is not trapped since it
always runs no matter what value %cmp is. But at runtime, we may have to
keep track of the code's CFG.

On other hand, the rules for Phi nodes/Arguments/Calls are defined in terms
of dynamic states for preciseness.

#Phi nodes depend on the operand corresponding to their dynamic predecessor
basic block.
#Function arguments depend on the corresponding actual argument values in
the dynamic callers of their functions.
#Call instructions depend on the ret instructions that dynamically transfer
control back to them.

I think Function arguments and calls are fine to keep track at runtime. But
Phi nodes have the same problem as the terminator instruction rule. My
confusion is the operational meaning of trapvalues.

Thanks
--
Jianzhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110412/027b4a99/attachment.html>