[LLVMdev] Two labels around one instruction in Codegen

Evan Cheng evan.cheng at apple.com
Wed Nov 7 13:57:32 PST 2007


On Nov 7, 2007, at 9:07 AM, Nicolas Geoffray wrote:

> Hi Evan,
>
> Evan Cheng wrote:
>>
>> 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.
>>
>>
>
> I think having variants (1) or differentiating ISD::{S|U}DIV from  
> other
> binary instructions (2) is what we would like to avoid.
>
> Following what we discussed with Duncan, what if we generate the  
> labels
> around a basic block? Is there a way then to ensure that the begin and
> end labels will actually bracket the instructions in the block? I've
> found that currently it's not the case, but perhaps it can trigger an
> easier solution than (1) or (2).

Ok, so it turns out the labels do not have to be just before / after  
the divide. So we don't have to use the MVT::Flag hackery. However,  
the second label must be after the divide. I think the solution is to  
add a trapping version of DIV (and others) and the second label can  
use its chain value as operand.

Evan

>
>
> Thanks,
> Nicolas
>
>> 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
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list