search for: integeroverflow

Edwin was asking about how we should handle PR3328, how we should make GEP respect -fwrapv etc. I wrote up some thoughts here if anyone is interested: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt -Chris

...gt; by widespread assumptions of C semantics. The current workaround is to use an alternate address space for your pointers. At some point we may extend the load/store/call instructions to specify their exact semantics similarly to the integer overflow proposal ( http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt ). Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090610/7f12b536/attachment.html>

On 07 Feb 2009, at 23:17, Chris Lattner wrote: > Edwin was asking about how we should handle PR3328, how we should make > GEP respect -fwrapv etc. I wrote up some thoughts here if anyone is > interested: > http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt The proposal suggests to change/split the existing sub/add/mul opcodes. This makes me wonder to what extent it is (currently, or ever) advisable for an external compiler to generate LLVM IR. Is there a plan to stabilise at some point and guarantee backwards compatibility to a certain e...

On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: >> The LLVM IR opcodes Add, Sub, and Mul have been each split into >> two. Add, Sub, and Mul now only handle integer types, and three >> new opcodes, FAdd, FSub, and FMul now handle floating-point types. > > Dan, > > Wondering the reason why there is no FDiv ? FDiv already exists; div was split quite a while ago. Dan

----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, June 16, 2009 7:49 AM Subject: Re: [LLVMdev] Upcoming API change: FAdd, FSub, FMul > > On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: > >>> The LLVM IR opcodes Add, Sub, and Mul have been each split

...esentation uses packed opcode fields. Dan On Feb 7, 2009, at 2:17 PM, Chris Lattner wrote: > Edwin was asking about how we should handle PR3328, how we should make > GEP respect -fwrapv etc. I wrote up some thoughts here if anyone is > interested: > http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

There's another point that hasn't been raised yet here, which is that the undefinedness of calling (void*) 0 is a property of C, not necessarily of the LLVM abstract language. I think you can make an excellent case that the standard optimizations should not be enforcing C language semantics, or at least should allow such optimizations to be disabled. Case in point —

...of C semantics. > > The current workaround is to use an alternate address space for your > pointers. At some point we may extend the load/store/call > instructions to specify their exact semantics similarly to the > integer overflow proposal ( http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt > ). I'll note that instcombine actually marks stores to null as unreachable regardless of the address space of the pointer, unless I'm missing something subtle. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pi...

> Dale Johannesen wrote: >> Paul Schlie wrote: >>> Dale Johannesen wrote: >>>> Marius Wachtler wrote: >>>> ... >>>> The call to address 0 gets removed. >>>> >>>> define i32 @t(i32 %a) noreturn nounwind readnone { >>>> entry: >>>> unreachable >>>> } >>>>