This is the mail archive of the 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: Some questions about pass web

On Wed, Sep 3, 2014 at 1:35 AM, Carrot Wei wrote:
> 1. It is well known that register renaming is a big help to register
> allocation, but in gcc's backend, the web pass is far before RA, there
> are about 20 passes between them. Does it mean register renaming can
> also heavily benefit other optimizations?

Yes - sometimes anyway. Most non-SSA data flow analyses can't look
through pseudos that have multiple non-overlapping live ranges. Think
constant/copy propagation, value numbering, etc. After passes that
duplicate basic blocks, and not renaming registers, you get false
dependencies that hide RA and scheduling opportunities. This is why
pass_web is after code-duplication transformations like (RTL) loop
unrolling but before the last RTL CPROP pass. The old RA couldn't do
register renaming, so something before RA had to take care of it.
Enter pass_web.

But this is less relevant in GCC today, where RTL code transformations
basically should be limited to simple local transformations, with the
more difficult global transformations already done on GIMPLE
(including live range splitting, part of out-of-SSA). On top of that,
IRA knows how to do some forms of live range splitting (but not within
loops, AFAIU, because a loop is a single region in IRA). If someone
would give some TLC to the RTL loop-unroll.c code for
IV-splitting/accumulator-expanding and make them enabled by default, I
doubt pass_web would be doing much at all.

> And the passes between them
> usually don't generate more register renaming chances?

Usually not. Most of them create new pseudos for newly inserted expressions.

Some passes are actually harmed by pass_web. auto_inc_dec is one of those.

> 2. It looks current web pass can't handle AUTOINC expressions, a reg
> operand is used as both use and def reference in an AUTOINC
> expression, so this def side should not be renamed. Pass web doesn't
> explicitly check this case, may rename the reg operand of AUTOINC
> expression. Is this expected because it is before auto_inc_dec pass?

You already found the DF_REF_READ_WRITE bits. pass_web also handles
match_dup constraints. That should be enough. If it is not, then
please file a bug report (and feel free to assign it to me).

> 3. Are AUTOINC expressions only generated by auto_inc_dec pass? All
> passes before auto_inc_dec including expand should not generate
> AUTOINC expressions, otherwise it will break web.

IIRC, it used to be that only push/pop could be AUTOINC before
auto_inc_dec. I'm not sure if this is still true today.


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