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. -Peter- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100809/3ad8b46a/attachment.html>
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/20100809/c3ec1ffd/attachment.html>
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/20100809/edc30562/attachment.html>