search for: unsafealgebra

I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. I would be inclined to...

Hi, Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using the

...ow, Warren <warren.ristow at sony.com>; llvm-dev at lists.llvm.org; Nicolai Hähnle <nhaehnle at gmail.com> > Subject: RE: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags > > I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. > > I would be...

...hether a transformation was done. More generally, my intended approach of doing this change (of removing the "fast" umbrella flag, and adding the two new flags "reassoc" and "libm"), is to audit all the places that currently enable an optimization based on whether ‘hasUnsafeAlgebra()’ is true (which essentially is asking whether _all_ the existing FastMathFlags are enabled), and see which of them can/should be controlled by one (or a subset of) the full set. So it's possible that a particular slow sequence of inline instructions you are transforming would be controlled b...

...been generated pre-r317488 or post-r317488 that means that: >> 1. a post-r317488 compiler is going to skip any optimization guarded by isFast for all pre-r317488 bitcode file (remember the afn bit is not set here) >> 2. a pre-r317488 compiler is going to run any optimization guarded by unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit (remember we repurposed UnsafeMath) >> >> Scenario #2 might be unlikely but we’re potentially breaking the semantic of the program. It is particularly dangerous because there is nothing that is going to tell us that we are in t...

...ilto:llvm-dev at lists.llvm.org>; Nicolai Hähnle <nhaehnle at gmail.com <mailto:nhaehnle at gmail.com>> > Subject: RE: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags > > I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. > > I would be...

Michael, Overall the code looks good. 80-cols: 2046 FMF.UnsafeAlgebra = 0 != (Record[OpNum] & (1 << bitc::FMF_UNSAFE_ALGEBRA)); 2047 FMF.NoNaNs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_NANS)); 2048 FMF.NoInfs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_INFS)); 2049 FMF.NoSignedZeros =...

...a bitcode file has been generated pre-r317488 or post-r317488 that means that: 1. a post-r317488 compiler is going to skip any optimization guarded by isFast for all pre-r317488 bitcode file (remember the afn bit is not set here) 2. a pre-r317488 compiler is going to run any optimization guarded by unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit (remember we repurposed UnsafeMath) Scenario #2 might be unlikely but we’re potentially breaking the semantic of the program. It is particularly dangerous because there is nothing that is going to tell us that we are in this situation “dow...

...ts.llvm.org<mailto:llvm-dev at lists.llvm.org>; Nicolai Hähnle <nhaehnle at gmail.com<mailto:nhaehnle at gmail.com>> Subject: RE: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. I would be inclined to...

...;milseman at apple.com> wrote: > > On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > >> Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. >> >> + bool any() { >> + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | >> + AllowReciprocal; >> + } >> > > Will do. > >> Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: >> >> SubclassOptionalData = >> (SubclassOptionalData &amp...

...file has been generated pre-r317488 or post-r317488 that means that: > 1. a post-r317488 compiler is going to skip any optimization guarded by isFast for all pre-r317488 bitcode file (remember the afn bit is not set here) > 2. a pre-r317488 compiler is going to run any optimization guarded by unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit (remember we repurposed UnsafeMath) > > Scenario #2 might be unlikely but we’re potentially breaking the semantic of the program. It is particularly dangerous because there is nothing that is going to tell us that we are in this situ...

...<nhaehnle at gmail.com <mailto:nhaehnle at gmail.com>> > *Subject:* RE: [llvm-dev] RFC: Consider changing the semantics > of 'fast' flag implying all fast-math-flags > > > > I don’t really like the idea of updating checks of > UnsafeAlgebra() to depend on all of the other flags. It seems > like it would be preferable to look at each optimization and > figure out which flags it actually requires. I suspect that in > many cases the “new” flag (i.e. allowing reassociation, etc.) > will be wha...

...enerated pre-r317488 or post-r317488 that means that: > 1. a post-r317488 compiler is going to skip any optimization guarded by > isFast for all pre-r317488 bitcode file (remember the afn bit is not set > here) > 2. a pre-r317488 compiler is going to run any optimization guarded by > unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit > (remember we repurposed UnsafeMath) > > Scenario #2 might be unlikely but we’re potentially breaking the semantic > of the program. It is particularly dangerous because there is nothing that > is going to tell us that we ar...

...enerated pre-r317488 or post-r317488 that means that: > 1. a post-r317488 compiler is going to skip any optimization guarded by > isFast for all pre-r317488 bitcode file (remember the afn bit is not set > here) > 2. a pre-r317488 compiler is going to run any optimization guarded by > unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit > (remember we repurposed UnsafeMath) > > Scenario #2 might be unlikely but we’re potentially breaking the semantic > of the program. It is particularly dangerous because there is nothing that > is going to tell us that we ar...

...ail.com>> >>> *Subject:* RE: [llvm-dev] RFC: Consider changing the semantics >>> of 'fast' flag implying all fast-math-flags >>> >>> >>> >>> I don’t really like the idea of updating checks of >>> UnsafeAlgebra() to depend on all of the other flags. It seems >>> like it would be preferable to look at each optimization and >>> figure out which flags it actually requires. I suspect that in >>> many cases the “new” flag (i.e. allowing reassociation, etc.) >&g...

Our processor also has some issues regarding the handling of denormals - scalar and vector - and we ran into a related problem only a few days ago. The v3.8 compiler has done a lot of good work on optimisations for floating-point math, but ironically one of them broke our implementation of 'nextafterf'. The desired code fragment (FP32) is: float xAbs = fabsf(x); since we know our

Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. + bool any() { + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | + AllowReciprocal; + } Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: SubclassOptionalData = (SubclassOptionalData & ~BitToSet) | (B * BitToSet); This is likely one iota slower.. but it sure is easier to...

...file has been generated pre-r317488 or post-r317488 that means that: > 1. a post-r317488 compiler is going to skip any optimization guarded by isFast for all pre-r317488 bitcode file (remember the afn bit is not set here) > 2. a pre-r317488 compiler is going to run any optimization guarded by unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit (remember we repurposed UnsafeMath) > > Scenario #2 might be unlikely but we’re potentially breaking the semantic of the program. It is particularly dangerous because there is nothing that is going to tell us that we are in this situ...

...t means that: >>> 1. a post-r317488 compiler is going to skip any optimization guarded by >>> isFast for all pre-r317488 bitcode file (remember the afn bit is not set >>> here) >>> 2. a pre-r317488 compiler is going to run any optimization guarded by >>> unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit >>> (remember we repurposed UnsafeMath) >>> >>> Scenario #2 might be unlikely but we’re potentially breaking the >>> semantic of the program. It is particularly dangerous because there is >>> not...

On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. > > + bool any() { > + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | > + AllowReciprocal; > + } > Will do. > Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: > > SubclassOptionalData = > (SubclassOptionalData & ~BitToSet) | (B * BitToSet); > This...