[LLVMdev] Optimization of sqrt() with invalid argument

[Sanjay Patel]

Yeah, it's a hack. I was just hoping to let everyone walk away a winner. :)

One more question then:
Why return zero instead of undef?

          if (V >= -0.0)
            return ConstantFoldFP(sqrt, V, Ty);
          else // Undefined
            return Constant::getNullValue(Ty);

Surely returning UndefValue::get(Ty) would allow greater havoc to ensue?
Maybe even the segfault that you suggested. :)

I don't think clang emits any warnings for the bogus C code...that would be
the nicer thing to do.

On Fri, Sep 26, 2014 at 1:20 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 26 September 2014 12:03, Sanjay Patel <spatel at rotateright.com> wrote:
> > This isn't purely a fast-math issue...ConstantFolding isn't using
> > enable-unsafe-fp-math to decide whether to emit the '0'. It's just
> looking
> > for the llvm intrinsic rather than a call to sqrt:
>
> Yep. As Hal said, the key option is -ffinite-math, which allows the
> front-end to emit that intrinsic in the first place. We document
> @llvm.sqrt's behaviour and it has no requirements to check
> unsafe-fp-math before folding.
>
> > So how about a front-end fix:
> > If the parameter is a negative constant, instead of converting the sqrt
> call
> > into the intrinsic, just leave it as-is regardless of fast-math.
>
> That sounds like a nasty hack to me. It covers only a very limited set
> of situations where this would happen. For example, almost certainly
> not:
>
> double foo() {
>   const double x = -1.0;
>   return sqrt(x);
> }
>
> Possibly not even (depending on how you define "constant"):
>
>     double foo() { return sqrt(-1.0f); }
>
> If we're going to change it I'd prefer the active decision in the mid-end.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140926/9a85fe80/attachment.html>