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
meiss...@linux.vnet.ibm.com
