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? -bw
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. - Devang
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
Hi Bill,> 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?a flag on each floating point operation, saying whether it does "exact" math or not? Ciao, Duncan.
Hi- Would this not be a good place to use the new metadata feature? If metadata indicating that a value is OK to have unsafe optimisations done on it is dropped, everything will still work correctly. Alastair On 14 Jan 2010, at 10:01, Duncan Sands wrote:> Hi Bill, > >> 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? > > a flag on each floating point operation, saying whether it does "exact" math or > not? > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Jan 14, 2010, at 2:01 AM, Duncan Sands wrote:> Hi Bill, > >> 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? > > a flag on each floating point operation, saying whether it does > "exact" math or > not?Yes, the right approach for this is to add flags to each fp operations just like the NUW/NSW bits on integer ops. We want the ability to represent the C99 pragmas which are scoped more tightly than a function body. This is actually really easy to do, the big issue is defining the 'bits' that we want to carry on each operation. For example, I think it would be reasonable to have an "assume finite" bit (saying no nan's / inf), it would also be useful to know you can do reassociation etc, useful to know that you don't care about signed zero, etc. I don't have enough expertise to propose exactly how this should work. -Chris