search for: pr27372

...of a real use-case. (That is to say, the code that was "failing" > due to reassociation didn't have an obvious fix like the reciprocal > situation, here, other than to turn off fast-math.) In fact, the > request to suppress reassociation was the motivation for creating > PR27372 in the first place (which eventually fed into this thread). I > have to say that on the reassociation point, my concern is that to > really suppress that, we will have to suppress so much, that there will > hardly be any point in using -ffast-math. > > > > I'd say your com...

...mation that's allowed by 'fast' (I presume it isn't), but I think reassociation would be better expressed by a separate flag, which could then be controlled independently via '-f[no]-associative-math' switch. Not having that flag exist separately in the FMF is the origin of PR27372. But creating that flag and using it in the appropriate places would still run into these problems of 'fast' implying all the others, which would make it impossible to disable reassociation while leaving all the other FMF transformations enabled. To ask a concrete question using the curre...

...mation that's allowed by 'fast' (I presume it isn't), but I think reassociation would be better expressed by a separate flag, which could then be controlled independently via '-f[no]-associative-math' switch. Not having that flag exist separately in the FMF is the origin of PR27372. But creating that flag and using it in the appropriate places would still run into these problems of 'fast' implying all the others, which would make it impossible to disable reassociation while leaving all the other FMF transformations enabled. > > To ask a concrete question usin...

...of a real use-case. (That is to say, the code that was "failing" > due to reassociation didn't have an obvious fix like the reciprocal > situation, here, other than to turn off fast-math.) In fact, the > request to suppress reassociation was the motivation for creating > PR27372 in the first place (which eventually fed into this thread). I > have to say that on the reassociation point, my concern is that to > really suppress that, we will have to suppress so much, that there will > hardly be any point in using -ffast-math. > > > > I'd say your...

...mation that's allowed by 'fast' (I presume it isn't), but I think reassociation would be better expressed by a separate flag, which could then be controlled independently via '-f[no]-associative-math' switch. Not having that flag exist separately in the FMF is the origin of PR27372. But creating that flag and using it in the appropriate places would still run into these problems of 'fast' implying all the others, which would make it impossible to disable reassociation while leaving all the other FMF transformations enabled. To ask a concrete question using the curre...

...say, the code that was "failing" >>> due to reassociation didn't have an obvious fix like the reciprocal >>> situation, here, other than to turn off fast-math.) In fact, the >>> request to suppress reassociation was the motivation for creating >>> PR27372 in the first place (which eventually fed into this thread). I >>> have to say that on the reassociation point, my concern is that to >>> really suppress that, we will have to suppress so much, that there will >>> hardly be any point in using -ffast-math. >>> &gt...

...mory is right) more of a real use-case. (That is to say, the code that was "failing" due to reassociation didn't have an obvious fix like the reciprocal situation, here, other than to turn off fast-math.) In fact, the request to suppress reassociation was the motivation for creating PR27372 in the first place (which eventually fed into this thread). I have to say that on the reassociation point, my concern is that to really suppress that, we will have to suppress so much, that there will hardly be any point in using -ffast-math. I'd say your comments here are very similar to wha...

...mation that's allowed by 'fast' (I presume it isn't), but I think reassociation would be better expressed by a separate flag, which could then be controlled independently via '-f[no]-associative-math' switch. Not having that flag exist separately in the FMF is the origin of PR27372. But creating that flag and using it in the appropriate places would still run into these problems of 'fast' implying all the others, which would make it impossible to disable reassociation while leaving all the other FMF transformations enabled. > > To ask a concrete question usin...

...a real use-case. (That is to say, the code that was "failing" > due to reassociation didn't have an obvious fix like the reciprocal > situation, here, other than to turn off fast-math.) In fact, the > request to suppress reassociation was the motivation for creating > PR27372 in the first place (which eventually fed into this thread). I > have to say that on the reassociation point, my concern is that to > really suppress that, we will have to suppress so much, that there > will hardly be any point in using -ffast-math. > > > > I'd say your...

...ay, the code that was "failing" >>> due to reassociation didn't have an obvious fix like the reciprocal >>> situation, here, other than to turn off fast-math.) In fact, the >>> request to suppress reassociation was the motivation for creating >>> PR27372 in the first place (which eventually fed into this thread). I >>> have to say that on the reassociation point, my concern is that to >>> really suppress that, we will have to suppress so much, that there >>> will hardly be any point in using -ffast-math. >>>...

...g the right thing for this test-case. Again FTR, the GCC behavior allows the re-association in the cases marked 'Error' above to happen. __________________________________________________________________ Note that the '-f[no-]associative-math' flag has other problems, reported in PR27372 (https://bugs.llvm.org/show_bug.cgi?id=27372). Those "other problems" are related to the fact that there isn't an LLVM IR fast-math-flag that explicitly indicates whether reassociation is enabled or disabled. As a consequence, the front-end essentially drops that flag on the floor....

...FTR, the GCC behavior allows the re-association in the cases marked > > 'Error' above to happen. > > __________________________________________________________________ > > Note that the '-f[no-]associative-math' flag has other problems, > reported in > > PR27372 (https://bugs.llvm.org/show_bug.cgi?id=27372). Those "other > problems" > > are related to the fact that there isn't an LLVM IR fast-math-flag that > > explicitly indicates whether reassociation is enabled or disabled. As a > > consequence, the front-end essenti...

Hi all, This is about https://reviews.llvm.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'):