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. Ciao! Steven