This is the mail archive of the gcc-patches@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: 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


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