On Jan 13, 2010, at 4:50 PM, Devang Patel wrote:> On Wed, Jan 13, 2010 at 4:20 PM, Bill Wendling <wendling at apple.com> wrote: >> Hi all, >> >> A quick question: >> >> The current implementation of the "allow unsafe math" option is to specify it via the TargetOptions object. However, this prevents the target-independent optimizer from using it. Are there any opinions (ha!) on how this could be achieved in a nice clean manner which doesn't require using the TargetOptions object in the optimizer? >> > > function attribute.Not a bad idea. However, how should it behave during inlining for LTO? (I really don't know the answer to this.) There are three options, that you mentioned off-line: A) Caller wins This could result in something the programmer didn't expect, possibly resulting in an incorrect answer. B) Don't inline We potentially miss important optimizations. C) Safety first The programmer could get code they didn't expect, but at least it won't result in an "incorrect" answer. I.e., it will be correct modulo LLVM bugs, but lacking any unsafe transforms they were expecting. -bw
On Jan 13, 2010, at 5:12 PM, Bill Wendling wrote:> > C) Safety first > The programmer could get code they didn't expect, but at least it won't result in an "incorrect" answer. I.e., it will be correct modulo LLVM bugs, but lacking any unsafe transforms they were expecting. >This one sounds like the sensible option to me. -Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100113/15251115/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100113/15251115/attachment.bin>
Bill Wendling wrote:> On Jan 13, 2010, at 4:50 PM, Devang Patel wrote: > >> On Wed, Jan 13, 2010 at 4:20 PM, Bill Wendling<wendling at apple.com> wrote: >>> Hi all, >>> >>> A quick question: >>> >>> The current implementation of the "allow unsafe math" option is to specify it via the TargetOptions object. However, this prevents the target-independent optimizer from using it. Are there any opinions (ha!) on how this could be achieved in a nice clean manner which doesn't require using the TargetOptions object in the optimizer? >>> >> >> function attribute. > > Not a bad idea. However, how should it behave during inlining for LTO? (I really don't know the answer to this.)A bit on the instruction, not unlike nsw/nuw/exact/inbounds. We could mark whether the fadd is reassociable or not: http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt This handles inlining properly. Nick> There are three options, that you mentioned off-line: > > A) Caller wins > This could result in something the programmer didn't expect, possibly resulting in an incorrect answer. > > B) Don't inline > We potentially miss important optimizations. > > C) Safety first > The programmer could get code they didn't expect, but at least it won't result in an "incorrect" answer. I.e., it will be correct modulo LLVM bugs, but lacking any unsafe transforms they were expecting. > > -bw > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
> There are three options, that you mentioned off-line: > > A) Caller wins > This could result in something the programmer didn't expect, possibly > resulting in an incorrect answer. > > B) Don't inline > We potentially miss important optimizations. > > C) Safety first > The programmer could get code they didn't expect, but at least it won't > result in an "incorrect" answer. I.e., it will be correct modulo LLVM > bugs, but lacking any unsafe transforms they were expecting.>From having worked extensively on FP code, I would prefer option B -- oftenthe most important property is that two calls to the same function with the same parameters produce the same result, you don't want the function to produce different results if it has been inlined or not even if the inlined result is more 'correct' (which would be the case with C). One example of the kind of problems you can get into is if you have a test to see which side of a plane a point is on and it produces different results from two different calls with the same point and the same plane. - Morten
On Jan 14, 2010, at 6:07 AM, Morten Ofstad wrote:>> There are three options, that you mentioned off-line: >> >> A) Caller wins >> This could result in something the programmer didn't expect, possibly resulting in an incorrect answer. >> >> B) Don't inline >> We potentially miss important optimizations. >> >> C) Safety first >> The programmer could get code they didn't expect, but at least it won't result in an "incorrect" answer. I.e., it will be correct modulo LLVM bugs, but lacking any unsafe transforms they were expecting. > > From having worked extensively on FP code, I would prefer option B -- often the most important property is that two calls to the same function with the same parameters produce the same result, you don't want the function to produce different results if it has been inlined or not even if the inlined result is more 'correct' (which would be the case with C). > > One example of the kind of problems you can get into is if you have a test to see which side of a plane a point is on and it produces different results from two different calls with the same point and the same plane. >Good point. :-) Though it looks like we would bypass this and go with flags on the individual instructions. Do you have any insight into Chris's response? -bw