[LLVMdev] llvm.sqrt intrinsic undefined behaviour

[Hal Finkel]

----- Original Message -----
> > I strongly disagree with this proposal.  The purpose of this
> > general
> > purpose intrinsic is to expose sqrt functionality present on many
> > of
> > the architectures LLVM supports.  If we defined its edge cases, we
> > won't be able to map it to target functionality freely on targets
> > whose
> > edge cases don't match that definition.
> 
> I agree the targets should be the primary focus, but a cursory search
> failed to find one whose sqrt instruction(s) didn't produce NaN for
> negative values; it's pretty much the only sane choice. Do they exist
> (perhaps odd GPUs or something that always traps)?
> 
> If not, perhaps we could sensibly decouple the errno stuff from the
> actual value produced: make no guarantees about what happens to the
> environment but specify the result.

FWIW, the fact that the current intrinsic (unlike all of the other libm-like intrinsics) does not have the same semantics and the corresponding libm function, means that we can only use it for autovectorization of sqrt() calls in finite-math mode. This is somewhat annoying for targets that can provide vectorized sqrt() functions more generally (whenever -fno-math-errno is in effect).

I would like to see some form of the sqrt intrinsic that is defined as the other ones are, as that will allow for autovectorization; either by changing the current definition, by adding some optional parameter, or by adding a new one.

 -Hal

> 
> Cheers.
> 
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory