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: peephole2: dead regs not marked as dead


On Tue, Nov 02, 2010 at 10:41:49AM +0100, Georg Lay wrote:
> This solution works:
> 
> Generating a named insn in andsi3-expander as
> 
> (define_insn_and_split  "..."
>   [(set (match_operand:SI 0 "register_operand"           "")
>         (and:SI (match_operand:SI 1 "register_operand"   "")
>                 (match_operand:SI 2 "const_int_operand"  "")))
>    (clobber (match_operand:SI 3 "register_operand"       ""))]
>   "...
>    && !reload_completed
>    && !reload_in_progress"
>   {
>     gcc_unreachable();
>   }
>   "&& 1"
>   [(set (match_dup 3)
>         (and:SI (match_dup 1)
>                 (match_dup 4)))
>    (set (match_dup 0)
>         (xor:SI (match_dup 3)
>                 (match_dup 1)))]
>   {
>     ...
>   })
> 
> The insn passes combine unchanged and gets split in split1 as expected :-)
> 
> What I do not understand is *why* this works.
> The internals "16.16 How to Split Instructions" mention two flavours of insn
> splitting: One after reload for the scheduler and one during combine stage, the
> latter just doing single_set --> 2 * single_set splits for insns that do *not*
> match during combine stage.

As I just wrote for another reply:

In the old days, define_split was only processed before each of the two
scheduling passes if they were run and at the very end if final finds an insn
string "#".

Now, it is always run several times.  Looking at passes.c, we see it is run:

    Before the 2nd lower subreg pass (which is before the 1st scheduling pass)
    After gcse2 and reload
    Just before the 2nd scheduling pass
    Before regstack elimination on x86
    Before the execption handling/short branch passes

I talked about this in part of my tutorial on using modern features in your MD
file that I gave at this year's GCC summit:
http://gcc.gnu.org/wiki/summit2010

In particular, go to pages 5-7 of my tutorial (chapter 6) where I talk about
scratch registers and allocating a new pseudo in split1 which is now always
run.

> However, this insn matches. So the combiner does'n split in accordance with
> internals doc. But the opportunity to use split1 is neither mentioned nor
> described in the internals.
> 
> I observed that the insn gets split in split1 even if the splitter produces more
> than two insns and also if optimization is off.
> 
> That's nice but can I rely on that behaviour? (As far as -O0 is concerned, I
> will emit the special insn just if optimization is turned on, but nevertheless
> it would be interesting to know why this works smooth with -O0 as I expected to
> run in unrecognizable insn or something like that during reload).

In gcc/passes.c the split passes are always run and do not depend on the
optimization flags, so yes, you can now rely on it with -O0.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com


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