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

[Sebastian Pop via llvm-commits]

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
>>
>>