This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: CRIS: Add hardware support for __builtin_ctz
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: rask at sygehus dot dk
- Cc: jesper dot nilsson at axis dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 5 Sep 2007 03:43:12 +0200
- Subject: Re: CRIS: Add hardware support for __builtin_ctz
> Date: Tue, 4 Sep 2007 21:28:13 +0200
> From: Rask Ingemann Lambertsen <rask@sygehus.dk>
> On Tue, Sep 04, 2007 at 04:30:48PM +0200, Jesper Nilsson wrote:
>
> > One question mark still remaining is why the define_expand for
> > ctzsi2 can't use the following:
> >
> > (define_expand "ctzsi2"
> > [(set (match_scratch:SI 2)
> > (match_operand:SI 0 "register_operand"))
...
> It should be fine, so that's a bug. It's unusual to have a (set (scratch)
> ...) construct, which is probably why it hasn't been caught until now.
I guess (I browsed [ab]*/*.md but lost interest and settled for "guess"
instead of "I know") it's because there's no port where a match_scratch is
re-used within the same body (just the result of the split etc).
I suspect net goodness would result, if (match_scratch:X N "<constraint>")
as a generator was changed to generate a new pseudoregister and the
generated matcher be (match_operand:X "register_operand" "<constraint>"),
instead of as now, generating SCRATCH:X and (match_operand:X
"scratch_operand" "<constraint>") for the matcher (see genrecog.c and
md.texi). Then perhaps retire SCRATCH. (Less RTL for the tree-huggers to
worry about! ;)
Doing this would mean one less special-case in several locations to ICE on
(QED), and just a few less lines in the register allocator. Of course,
there'd also be a few extra pseudos generated, so a net benefit with the
current allocator (at least :) isn't guaranteed.
Docs and code seems to agree that scratch_operand just matches SCRATCH or
a hard-register. Hence, from reading the code, and if the rule that the
predicate is always the prerequisite for a match was actually followed (I
haven't stepped with gdb through it), i386.md will not get a stack-slot
for any of its (clobber (match_scratch:DI 0 "=rm")). I suspect it still
does and wants to, so perhaps better use "nonimmediate_operand" in the
matcher instead...
(FWIW, at a glance genemit.c:output_add_clobbers and both add_clobbers
callers look like they'd cope with such a change, but I guess special care
would be needed in genpeep.c.)
brgds, H-P