[LLVMdev] [PATCH] Re: Overflow trap

Peter Housel housel at acm.org
Sat Aug 21 23:10:59 PDT 2010


The enclosed patch adds a llvm.x86.int(i8) intrinsic expanding to the INT or INT3 instruction as appropriate. I haven't yet figured out the best way to select for the INTO instruction across basic blocks (hints would be welcome), but that can be added later with no changes in semantics.

-Peter-

On Aug 9, 2010, at 6:05 PM, Chris Lattner wrote:

> After chatting on IRC, Peter wants a very specific interrupt (int4 on x86).  I suggested he add a new llvm.x86.int(i32) intrinsic, and use the existing branch on llvm.sadd.with.overflow intrinsic.  The x86 backend can then turn jo+int4 into into when reasonable.
> 
> -Chris
> 
> On Aug 9, 2010, at 5:45 PM, Chris Lattner wrote:
> 
>> 
>> On Aug 9, 2010, at 10:44 AM, Peter S. Housel wrote:
>> 
>>> Several instruction set architectures include arithmetic operations that can trap on overflow, or support this feature with a separate trap-on-overflow-flag instruction (such as the x86 INTO instruction).
>>> 
>>> 
>>> I am adding a back-end to the Open Dylan compiler to generate LLVM IR. The original back-end, which generates x86 machine code, makes use of the INTO instruction, and the runtime turns the resulting INT 4 into a language-level exception. In order to support this not-uncommon requirement using LLVM, I see three alternatives:
>>> 
>>> 1. Add llvm.sadd.with.overflow.trap.*, … intrinsics corresponding to the current llvm.sadd.with.overflow.*, … intrinsics to LLVM and the current code generators.
>>> 
>>> 2. Add a single llvm.trap.overflow intrinsic to LLVM and the current code generators, and ensure that the code generators can generate the proper arithmetic-with-overflow-trap or trap-on-overflow-flag instruction when it is executed conditionally based on the output of one of the llvm.sadd.with.overflow.* etc. intrinsics.
>>> 
>>> 3. Don’t try to solve this problem for LLVM in general but use inline assembly for these few operations in my back-end.
>>> 
>>> Which alternative should I pursue? The third is obviously the easiest for me, but other LLVM users would benefit from the other two.
>>> 
>>> 
>> 
>> I don't understand... why can't you use a branch on a llvm.sadd.with.overflow that goes to an llvm.trap?  This is what clang does with -ftrapv.
>> 
>> -Chris
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100821/1e095e7c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: int.diff
Type: application/octet-stream
Size: 2184 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100821/1e095e7c/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100821/1e095e7c/attachment-0001.html>


More information about the llvm-dev mailing list