This is the mail archive of the
mailing list for the GCC project.
Re: Some questions about pass web
- From: Carrot Wei <carrot at google dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2014 10:10:46 -0700
- Subject: Re: Some questions about pass web
- Authentication-results: sourceware.org; auth=none
- References: <CAEe8uECWjpB7LqX_k91Vs2W6jmX4BqwwBmyEcxnmRu8=hmy_vA at mail dot gmail dot com> <CABu31nN5RUoMywRxP=u0ijGjYnkHQeey=F4CzgEymQdEwg_63w at mail dot gmail dot com>
On Wed, Sep 3, 2014 at 1:29 AM, Steven Bosscher <firstname.lastname@example.org> wrote:
> 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).
Bug entry filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63156.
Debugging shows that DF_REF_READ_WRITE is not set for the operand of
post_inc, may be a dataflow problem?