search for: 107114

...on > vs library is equivalent. I haven't defined "libm" explicitly. The concept of "reassoc" and "libm" are a result of the discussion last November. The "libm" aspect in particular, came from: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html It was intended to mean actual library functions, which is what I thought you were referring to when you said "This option also relaxes the precision of commonly used math functions." From your elaboration describing it as a sequence of inline instructions, I think whether "li...

...on > vs library is equivalent. I haven't defined "libm" explicitly. The concept of "reassoc" and "libm" are a result of the discussion last November. The "libm" aspect in particular, came from: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html It was intended to mean actual library functions, which is what I thought you were referring to when you said "This option also relaxes the precision of commonly used math functions." From your elaboration describing it as a sequence of inline instructions, I think whether "li...

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