Re: Question about how to fix PR69052

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Mon, Jan 25, 2016 at 7:51 PM, Jeff Law <law@redhat.com> wrote:
> On 01/25/2016 11:42 AM, Bin.Cheng wrote:
>>
>>
>> Yuri Rumyantsev suggested we may add a hook to handle GOT related
>> instruction propagation specially so it won't be hoisted out.  Is a
>> hook at this stage sounds feasible?
>
> I think that would be a mistake.  ISTM this really needs to be cost driven.
>
>>
>> Also it would be great if we can abstract an interface out of combine,
>> and the interface can be used in other passes checking whether
>> instructions can be merged or not.  I know this will be even harder
>> than emulation of combine behavior.
>>
>> Another point is if we can do combine among different basic blocks?
>
> No, the combiner works within a basic block only.  There was a group, I
> believe in Moscow, that worked on a cross-block combiner.  It was discussed
> at the Cauldron in California a few years back.  I don't know if they did
> any further work on those ideas.
>
> Is the issue here not knowing when the loop invariant can be forward
> propagated back into the memory reference -- and for complex RTL like you
> cited, you ultimately determine that no it can't be propagated and thus
> increase its invariant cost?
Yes, loop invariant now increased invariant cost if the invariant
can't be propagated into address expression.  Problem is we check
propagation by simply replacing use with def in memory reference then
verifying result insn with verify_changes.  Apparently more advanced
transforms are necessary, just like what combine does.
I am surprised that rtl_fwprop_addr doesn't handle this either, it's
an exact address expression propagation example.

Thanks,
bin

>
> jeff