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


On Wed, Sep 3, 2014 at 1:29 AM, Steven Bosscher <stevenb.gcc@gmail.com> 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?

thanks
Guozhi Wei


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