llvm dev - Apr 2011 - [LLVMdev] About trapvalues

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>

On Apr 12, 2011, at 9:59 AM, Jianzhou Zhao wrote:
> 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.
Yes. I believe fully precise trap tracking would require a
highly elaborate combination of static and dynamic analysis, 
and at the whole-program level.
> 
> 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.
The main intuition for trap values is that they can occur on
speculative code paths, and if a speculative path is discarded,
its trap values are harmlessly discarded as well. But if a trap
value reaches a non-speculative path, it triggers actual
undefined behavior.

It's unfortunate that this simple concept ended up being so
hard to verify dynamically. But, for example, dependencies have
to be fully precise even across things like call boundaries,
because neither inlining nor outlining should be able to change
program semantics. Perhaps it would be practical to develop a
conservative tracker which could catch common problems though.

Dan