search for: hasunsafealgebra

On 8 February 2016 at 19:25, James Molloy <James.Molloy at arm.com> wrote: >> For 16275, the fix is to disable loop vect. for no-fast-math + hasUnsafeAlgebra. > > Do you think there is a set of people that care about IEEE accuracy in so far that they don't want FTZ, but *are* happy to reassociate FP operations? That seems fairly niche to me? No. But I also don't want to disable the vectorizer for integer arithmetic. I'm guessing hasUn...

...the loop vectorizer produces vector code without -ffast-math. Are you saying we should disable it altogether for all architectures that claim to follow the new standard? Inner loops can be "vectorized" by SLP using only VFP instructions. The implementation seem to have moved to Inst->hasUnsafeAlgebra(), so we may need to return false in the legalization phase if the flag is omitted and any instruction has unsafe algebra. > The SLP vectoriser however should theoretically take non-fast scalars and produce non-fast vectors. Similarly people will hand-write vector IR, or generate it from other...

...l whether 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...

...n 8 Feb 2016, at 20:51, Renato Golin <renato.golin at linaro.org> > > wrote: > > > > On 8 February 2016 at 19:25, James Molloy <James.Molloy at arm.com> > > wrote: > >>> For 16275, the fix is to disable loop vect. for no-fast-math + > >>> hasUnsafeAlgebra. > >> > >> Do you think there is a set of people that care about IEEE > >> accuracy in so far that they don't want FTZ, but *are* happy to > >> reassociate FP operations? That seems fairly niche to me? > > > > No. But I also don't want to di...

Folks, I'm now looking at https://llvm.org/bugs/show_bug.cgi?id=16274, which seems to have some support in the vectorizer, but not as we need for this particular case. I may have missed something obvious, please let me know if there is a better way. As you already know, ARM has two FP instruction sets: VFP and NEON. VFP applies to single FP registers while NEON is a full SIMD. The problem is

...l whether 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...

On 10/02/2017 11:10 AM, Bruce Hoult via llvm-dev wrote: > Is there anything that means, in particular, "go fast, even if it > means not all bits are significant"? > > I'm currently working on an llvm-based compiler for a GPU that is > optomised for OpenGL, where 16 bit FP may not be quite accurate enough > (or may be in some cases), but 32 bit FP is overkill. A