This is the mail archive of the
mailing list for the GCC project.
Re: Question about how to fix PR69052
- From: Jeff Law <law at redhat dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 25 Jan 2016 12:51:53 -0700
- Subject: Re: Question about how to fix PR69052
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci280ObgaSxzCBiKKBfKONeYsXOue8i84hH=pDwynhC4PNQ at mail dot gmail dot com>
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.
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.
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?
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?