search for: unsafemath

...pectations. Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? (I believe we should!) * Context * With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. From a bitcode perspective, this change looks like this: Before r317488 we had 6 bits that respectively represented: UnsafeMath nnan ninf nsz arcp contract *unset* (The order may not match wh...

...e bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp...

...ions. > > Should we bump the bitcode version because of that and have the > autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 / r317488 we got rid of the umbrella > UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > ar...

...ions. > > Should we bump the bitcode version because of that and have the > autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 / r317488 we got rid of the umbrella > UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > ar...

...e bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? > (I believe we should!) > > > * Context * > > With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp...

...e of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? >> (I believe we should!) >> >> >> * Context * >> >> With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. >> >> From a bitcode perspective, this change looks like this: >> Before r317488 we had 6 bits that respectively represented: >> >> UnsafeMath >> nnan >&...

...at and have the >>> autoupgrader properly rewrite the fast-math to preserve that semantic? >>> (I believe we should!) >>> >>> >>> * Context * >>> >>> With https://reviews.llvm.org/D39304 / r317488 we got rid of the >>> umbrella UnsafeMath flag and introduced 3 more flags that better represent >>> the different things that happen under fast-math. >>> >>> From a bitcode perspective, this change looks like this: >>> Before r317488 we had 6 bits that respectively represented: >>> >>>...

...he bitcode version because of that and have the >> autoupgrader properly rewrite the fast-math to preserve that semantic? >> (I believe we should!) >> >> >> * Context * >> >> With https://reviews.llvm.org/D39304 / r317488 we got rid of the >> umbrella UnsafeMath flag and introduced 3 more flags that better represent >> the different things that happen under fast-math. >> >> From a bitcode perspective, this change looks like this: >> Before r317488 we had 6 bits that respectively represented: >> >> UnsafeMath >> nna...

...autoupgrader properly rewrite the fast-math to preserve that semantic? >>>> (I believe we should!) >>>> >>>> >>>> * Context * >>>> >>>> With https://reviews.llvm.org/D39304 / r317488 we got rid of the >>>> umbrella UnsafeMath flag and introduced 3 more flags that better represent >>>> the different things that happen under fast-math. >>>> >>>> From a bitcode perspective, this change looks like this: >>>> Before r317488 we had 6 bits that respectively represented: >>&...

.... > > That said, I don't think anyone would object to making VFP codegen > available under non-Darwin triples. It's just a matter of making it happen. > Hi Owen, ARMSubtarget::resetSubtargetFeatures(StringRef CPU, StringRef FS) has a check to see if the target is Darwin or if UnsafeMath is enabled to set the UseNEONForSinglePrecisionFP, but only for A5 and A8, where this was a problem. Maybe I was too conservative on my fix. Tobi, The march=arm option would default to ARMv4, while mattr=+neon would force NEON, but I'm not sure it would default to A8, which would be a weird c...

...nly an IR level > definition, the backend only inherited these per instruction flag > very recently. It has been entirely converted to use these, and it > still uses a global flag in some places. > The line you’re touching in your patch for instance is about this > legacy: > if (!UnsafeMath && !Flags->hasAllowReciprocal()) > The first flag is the global “fast-math” mode on the backend, which > is not as fine grain as the per-instruction model. > The second flag is the “per instruction” flag, which is the model we > aim at. > We should get rid of the “global...

On Jun 6, 2013, at 8:35 PM, Tobias Grosser <grosser at google.com> wrote: > I understand that some users do not require 754 compliant floating point behavior (clang on darwin?), which means they would probably not need this change. However, it should also not hurt them performance-wise as such users would probably set the relevant global fast-math flags to reduce the precision

...ion, where I honestly > don't have any opinion on for clang. The best is probably to mirror the gcc > behavior on linux targets. > Not really, since GCC has no special behaviour for Darwin, AFAIK. My change will only generate SP-FP on NEON for A5 and A8 and only if it's Darwin or UnsafeMath is on, which seems not to be the case for you, so I don't think the problem is in that area. It's possible that some passes are not consulting that flag when generating NEON SP-FP. If that's true, this is definitely a bug. When I changed that, for VMUL.f32, it worked (ie. generated VFP...

Hi, I was recently looking into the translation of LLVM-IR vector instructions to ARM NEON assembly. Specifically, when this is legal to do and when we need to be careful. I attached a very simple test case: define <4 x float> @fooP(<4 x float> %A, <4 x float> %B) { %C = fmul <4 x float> %A, %B ret <4 x float> %C } If fooP is compiled with "llc -march=arm

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'):

...where I honestly don't have any opinion on for clang. The best is probably to mirror the gcc behavior on linux targets. > > Not really, since GCC has no special behaviour for Darwin, AFAIK. > > My change will only generate SP-FP on NEON for A5 and A8 and only if it's Darwin or UnsafeMath is on, which seems not to be the case for you, so I don't think the problem is in that area. It's possible that some passes are not consulting that flag when generating NEON SP-FP. If that's true, this is definitely a bug. > > When I changed that, for VMUL.f32, it worked (ie. gen...

...x-A*), and it's neither A5 nor A8, do we > still want to generate single-precision float on NEON when non-Darwin and > safe math? I don't think so. Possibly, that condition should be extended to > ignore the CPU you're using and *only* emit NEON SP-FP when either Darwin > or UnsafeMath are on. Renato: When to set which subtarget feature is a policy decision, where I honestly don't have any opinion on for clang. The best is probably to mirror the gcc behavior on linux targets. My current goal is to understand the implications of certain features and to make sure a tool u...

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "James Molloy" <James.Molloy at arm.com>, "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" > <aschwaighofer at apple.com>, "LLVM Dev" <llvm-dev at

...t NEON's only problem is the Flush-to-zero behaviour, > which is non-compliant. > > NEON deals with NaNs and Infs in the way specified by the standard and > should not cause any concern to us. But we don't seem to have a flag > specifically to denormals, so I think using the UnsafeMath is the > safest option for now. > > On 11 February 2016 at 01:15, Hal Finkel <hfinkel at anl.gov> wrote: >> nsz >> No Signed Zeros - Allow optimizations to treat the sign of a zero argument or result as insignificant. > > In both VFP and NEON, zero signs are sig...

...ly don't have any opinion on for clang. The best is probably to mirror the gcc behavior on linux targets. >> >> Not really, since GCC has no special behaviour for Darwin, AFAIK. >> >> My change will only generate SP-FP on NEON for A5 and A8 and only if it's Darwin or UnsafeMath is on, which seems not to be the case for you, so I don't think the problem is in that area. It's possible that some passes are not consulting that flag when generating NEON SP-FP. If that's true, this is definitely a bug. >> >> When I changed that, for VMUL.f32, it worked (...