[llvm] r277690 - Revert "GVN-hoist: enable by default" & "Make GVN Hoisting obey optnone/bisect."

[Daniel Berlin via llvm-commits]

Oh, you hoisted them backwards.


On Thu, Aug 4, 2016 at 12:13 PM, Sebastian Pop <sebpop at gmail.com> wrote:

> Reduced test:
>
> $ opt -gvn-hoist hoist-call.ll
> Instruction does not dominate all uses!
>   %0 = call float @llvm.fabs.f32(float %__b)
>   %cmpinf10 = fcmp oeq float %0, 0x7FF0000000000000
>
> $ cat hoist-call.ll
> define void @__mulsc3(float %__b) minsize {
> entry:
>   br label %if.then
>
> if.then:                                          ; preds = %entry
>   br i1 undef, label %if.then8, label %lor.lhs.false
>
> lor.lhs.false:                                    ; preds = %if.then
>   %0 = call float @llvm.fabs.f32(float %__b) #2
>   %cmpinf7 = fcmp oeq float %0, 0x7FF0000000000000
>   unreachable
>
> if.then8:                                         ; preds = %if.then
>   %1 = call float @llvm.fabs.f32(float %__b) #2
>   %cmpinf10 = fcmp oeq float %1, 0x7FF0000000000000
>   ret void
> }
>
> declare float @llvm.fabs.f32(float)
>
>
> On Thu, Aug 4, 2016 at 1:28 PM, Sebastian Pop <sebpop at gmail.com> wrote:
> > Thanks Bruno for the testcase.
> > I was able to reproduce the fail with clang and the preprocessed file.
> > I will investigate the reason of the ICE, and send a patch to fix this
> problem.
> >
> > Thanks,
> > Sebastian
> >
> > On Thu, Aug 4, 2016 at 12:25 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >> I can't get gvn-hoist to fail on this testcase no matter what i do,
> even on
> >> darwin, with my own built clang at the same rev.
> >>
> >>
> >> On Thu, Aug 4, 2016 at 10:10 AM, Bruno Cardoso Lopes
> >> <bruno.cardoso at gmail.com> wrote:
> >>>
> >>> Hi Sebastian,
> >>>
> >>> Attached the reproducer with a preprocessed and bitcode testcase. Let
> >>> me know if you need any help.
> >>>
> >>> On Thu, Aug 4, 2016 at 7:30 AM, Sebastian Pop <sebpop at gmail.com>
> wrote:
> >>> > I will need a preprocessed file or a reduced testcase:
> >>> > with the same cmake options as the bot, I was not able to see the
> fail
> >>> > on x86_64-linux.
> >>> > This was both when compiling with the system's gcc 5.4 and clang 3.8.
> >>> > The fail may be related to the libc of the bot.
> >>> >
> >>> > Thanks,
> >>> > Sebastian
> >>> >
> >>> > On Thu, Aug 4, 2016 at 8:10 AM, Sebastian Pop <sebpop at gmail.com>
> wrote:
> >>> >> I am looking at this fail.
> >>> >> I think I have enough information from the bot on how to reproduce
> the
> >>> >> bug.
> >>> >>
> >>> >> On Thu, Aug 4, 2016 at 12:44 AM, Daniel Berlin <dberlin at dberlin.org
> >
> >>> >> wrote:
> >>> >>>
> >>> >>>
> >>> >>> On Wed, Aug 3, 2016 at 10:17 PM, Bruno Cardoso Lopes
> >>> >>> <bruno.cardoso at gmail.com> wrote:
> >>> >>>>
> >>> >>>> Hi Daniel,
> >>> >>>>
> >>> >>>> On Wed, Aug 3, 2016 at 9:59 PM, Daniel Berlin <
> dberlin at dberlin.org>
> >>> >>>> wrote:
> >>> >>>> > so here's the super-curious question in my mind:
> >>> >>>> >
> >>> >>>> > Why didn't this break when this was enabled by default for like
> a
> >>> >>>> > month
> >>> >>>> > before :)
> >>> >>>>
> >>> >>>> Not really sure why, I was not following the bots back then.
> >>> >>>
> >>> >>>
> >>> >>> Yeah, it's semi-rhetorical. It's just really odd, and makes me
> think
> >>> >>> it's
> >>> >>> related to one or more of the optimizations sebastian added (for
> >>> >>> example,
> >>> >>> not recomputing DFS numbers).
> >>> >>>
> >>> >>>>
> >>> >>>> Where
> >>> >>>> there many changes following up the time it got off? Another
> >>> >>>> possibility is that the bot could have been broken by another
> change
> >>> >>>> that hid this?
> >>> >>>> I can get my hands on the reproducer and send to you tomorrow if
> >>> >>>> that's
> >>> >>>> helpful.
> >>> >>>>
> >>> >>>
> >>> >>> That would be really helpful.
> >>> >>>
> >>> >>>>
> >>> >>>> -Bruno
> >>> >>>>
> >>> >>>> --
> >>> >>>> Bruno Cardoso Lopes
> >>> >>>> http://www.brunocardoso.cc
> >>> >>>
> >>> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Bruno Cardoso Lopes
> >>> http://www.brunocardoso.cc
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160804/90159625/attachment.html>