Hi,<br><br>I am trying to understand trapvalues<br>  <a href="http://llvm.org/docs/LangRef.html#trapvalues">http://llvm.org/docs/LangRef.html#trapvalues</a><br>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<br>
<br>  # 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.<br>
<br>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.<br><br>entry:<br>  ...<br>  %br i1 %cmp, %true, %end           ; Branch to either destination.<br>
<br>true:<br>    ...<br>    br label %end<br><br>end:<br>    ...<br>    volatile store i32 0, i32* @g      ; %end is control-equivalent to %entry<br>                                                                                ; so this is defined (ignoring earlier<br>
                                            ; undefined behavior in this example).<br><br>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. <br>
<br>On other hand, the rules for Phi nodes/Arguments/Calls are defined in terms of dynamic states for preciseness.<br><br>#Phi nodes depend on the operand corresponding to their dynamic predecessor basic block.<br>#Function arguments depend on the corresponding actual argument values in the dynamic callers of their functions.<br>
#Call instructions depend on the ret instructions that dynamically transfer control back to them.<br><br>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.<br>
<br>Thanks<br>--<br>Jianzhou<br>