[llvm] r258428 - [LibCallSimplifier] don't get fooled by a fake fmin()

Sanjay Patel via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 21 15:22:03 PST 2016


Sorry - I missed your mail before I committed another small cleanup step:
http://reviews.llvm.org/rL258446

Hopefully, we don't have any more bugs like PR26211 now, but I agree that
there's more to do here.

We do the signature check for any FP type and then do it again to decide if
a double->float shrink is applicable. I think we could have the helper
return the type instead of a bool and avoid that. And as I noted in the
commit message, we could hoist that check to optimizeCall(), so it's not
duplicated all over the place. Another possibility would be to hoist the
shrinking transforms from all of the individual optimization functions to
optimizeCall(). I think it makes it more confusing to intermingle those
optimizations.



On Thu, Jan 21, 2016 at 2:48 PM, Davide Italiano <davide at freebsd.org> wrote:

> On Thu, Jan 21, 2016 at 3:19 PM, Sanjay Patel via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > Author: spatel
> > Date: Thu Jan 21 14:19:54 2016
> > New Revision: 258428
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=258428&view=rev
> > Log:
> > [LibCallSimplifier] don't get fooled by a fake fmin()
> >
> > This is similar to the bug/fix:
> > https://llvm.org/bugs/show_bug.cgi?id=26211
> > http://reviews.llvm.org/rL258325
> >
> > The fmin() test case reveals another bug caused by sloppy
> > code duplication. It will crash without this patch because
> > fp128 is a valid floating-point type, but we would think
> > that we had matched a function that used doubles.
> >
> > The new helper function can be used to replace similar
> > checks that are used in several other places in this file.
> >
>
> This is nice. When I first started looking at LibCallSimplifier I
> noticed (and was disturbed) by all the duplicated checks, so I factored
> out some of them.
> Unfortunately there's still a lot more to do, so thanks for picking up
> the slack. I think at some point we might sit down and discuss how to
> refactor this properly.
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160121/a63bede4/attachment.html>


More information about the llvm-commits mailing list