This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, LRA] Remove REG_DEAD and REG_UNUSED notes.


On Wed, Sep 25, 2013 at 4:55 PM, Vladimir Makarov wrote:
> On 09/24/2013 03:40 PM, Mike Stump wrote:
>> On Sep 24, 2013, at 12:23 PM, Steven Bosscher wrote:
>>> On Tue, Sep 24, 2013 at 5:03 PM, Eric Botcazou wrote:
>>>>> This patch removes REG_DEAD and REG_UNUSED notes
>>>> DF framework is supposed to do it for you.
>>> Unfortunately LRA uses its own DF framework.
> I'd say fortunately.  Otherwise, LRA would decrease whole compiler speed
> by upto 10%.  I can say it because of the first version of LRA was based
> on DF framework.

You've said that before, but I don't think you ever really gave the DF
framework a fair chance.

There are many knobs and switches on DF that can make or ruin its
performance. I don't remember seeing your DF-based LRA code, or you
seeking advice from DF maintainers. As you may remember, LRA had a
great number of relatively easy compiler speed improvements left just
before the merge from the lra-branch to the trunk. We will never know
whether your DF-based LRA would have been competitive, given a little
more care and effort, and some help from people who know the DF
framework well.

But it doesn't matter anymore now, anyway. IRA+LRA are fine the way it
is, IMHO. IRA+LRA needs to have a different view on registers than
almost all other passes need: allocnos vs. REGs, insn operand number
matters more, LRA needs to see the MEM if the registers are used in an
address, etc. I'm not sure DF is the right framework for IRA+LRA to do
their job!

It's only unfortunate that LRA doesn't, and maybe can't use DF,
because I just would have liked to see the whole compiler use a single
framework, to improve maintainability (as in this case: managing
REG_DEAD/REG_UNUSED notes in only one place) and to let all passes
benefit from any work done to improve the framework.


> I'd be glad if we move to DF without compilation time degradation.
>
> I already wrote that DF-design (although it has a nice API which is good
> for prototyping) has a bad design with resource usage point of view.
> Keeping a lot of duplicated info by RTL side increases memory footprint
> very much, worsens data locality, and slows down the compiler.

The memory footprint is still a significant downside, but the other
two points are not. Data locality can be a lot better if the DF caches
are used.

For example: I rewrote the RTL CPROP pass using the DF operand caches
and that took the pass off the list of compile time bottlenecks
(before 3-4% compile time on preprocessed GCC source; now less than
1%). Most of the speedup came from fewer L2 cache misses, because
CPROP doesn't walk insn patterns anymore in its dataflow analysis
phase.

The DF operand caches are compiler speed killers if used incorrectly,
e.g. automatic updating after each change for passes that make a lot
of changes. Manual updating is the solution used by such passes. I can
only speculate, but perhaps the DF-based LRA used an inappropriate DF
caches update mode.

(What's still not done well in the DF framework, is re-using the
memory allocated for the DF caches...)


>  As I
> remember correctly, GCC steering committing permitted 5% compiler time
> degradation as a criterium to include it into the trunk and DF achieved
> this with difficulties.

In fact, as I remember it, the df-branch at the time of the merge was
still above that 5% threshold. Was it below 5% slowdown before the
merge?

Either way: Much of that slowdown was due to having the LR, RU, and
LIVE problems separate. The RU and LIVE problems were merged before
GCC 4.3 and that solved much of the slowdown (and a significant
portion of the memory footprint issues) . Moreover, the solver itself
was rewritten before GCC 4.3 was released, and all DF problems
benefited from that. Another big compiler speed problem was with the
RD problem that fwprop used at the time. The RD problem can now be
much faster if reaching defs are pruned using liveness, and all RD
users benefit from this. Single framework change, many passes benefit!

Ciao!
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]