[LLVMdev] Two labels around one instruction in Codegen

[Evan Cheng]

On Nov 5, 2007, at 11:52 AM, Nicolas Geoffray wrote:

> Hi everyone,
>
> In order to have exceptions for non-call instructions (such as sdiv,
> load or stores), I'm modifying codegen so that it generates a  
> BeginLabel
> and an EndLabel between the "may throwing" instruction. This is  
> what the
> codegen of an InvokeInst does.
>
> However, when generating native code, only BeginLabel is generated,  
> and
> it is generated after the instruction. I'm not familiar with DAGs  
> in the
> codegen library, so here are my 2-cents thoughts why:
>
> 1) BeginLabel and EndLabel are generated with:
>   DAG.setRoot(DAG.getNode(ISD::LABEL, MVT::Other, getRoot(),
>                             DAG.getConstant({Begin|End}Label,  
> MVT::i32)));
>
> This seems to work with InvokeInst instructions, because the root  
> of the
> DAG is modified by the instruction. With instructions such as sdiv,  
> the
> root is not modified: the instruction only lowers itself to:
> DAG.getNode(OpCode, Op1.getValueType(), Op1, Op2)

DIV does not produce a chain. So the second LABEL's only operand is  
the first LABEL. The only ordering that's ensure are between the 2  
labels so it's very possible the DIV node will be scheduled after  
both labels. Actually this scheme doesn't even ensure there won't be  
anything scheduled between the first label and the DIV node. I am  
assuming that'd badness.

>
> Which probably makes the codegen think EndLabel and BeginLabel are in
> the same place
>
> 2) Since there is no ordering between the node for the sdiv  
> instruction
> and the labels, the sdiv instruction can be generated anywhere.

Right.

>
> These assumptions may be wrong, but it's the best I could come up  
> with ;-).
>
> If someone could correct me and help me found how to correctly  
> generate
> two labels between one instruction, that would be great! :)

One way to solve this right now is to use flag value. But that means  
ISD::LABEL, ISD::{S|U}DIV, ISD::LOAD, ISD::STORE will be marked  
SDNPOutFlag and SDNPOptInFlag. But that's just yucky. Perhaps we need  
to add new variants of these nodes and leave the current opcodes as  
non-faulting. But I am not certain that's a very clean solution either.

Evan

>
> Thanks,
> Nicolas
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev