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: [rfc] subreg lowering pass / Overcoming double-set difficulties for CC re-use


On Sun, 2 Jul 2006, [utf-8] Björn Haase wrote:
> Ian Lance Taylor wrote on Montag, 19. Juni 2006 20:29 :
> > Obviously the MD file would have to be modified to add the double-SET
> > instructions.  Maybe most of the CC0 machine descriptions already have
> > those operations--I haven't checked.

No, that's part of the pattern explosion you'll see when
adjusting the post-cc0 port to get the cc0 performance. :(

When cc0, the set patterns don't have the clobber/set variants;
there's just the "main" setting effect; no parallel.

> Maybe the best way to facilitate the task a bit would be to modify the md
> parser programs so that they now how to handle something like
> (define_double_insn) where instead of one single RTL template one would be
> giving two alternative RTL templates. Typically the first one of the two
> patterns would be of the (single-set-with-clobber) type and the second one
> would be a true double-set insn.

(Where are we on proposals like this?  Aw, I'll presume nothing
has changed; no such new .md feature yet.)

I've thought about how to avoid pattern explosion post-cc0 and I
suggest getting this functionality with a more general feature:
make define_code_macro take operands.  Then you can make the
iterator definition part like:
 (define_code_macro (CCpart x)
   [(clobber CC_REG) (set CC_REG (compare:CC x const_int 0))])

and the user part; the second part of the
set-main-stuff-and-set/clobber-cc parallel will be like:
 (CCpart (match_dup 1))

Further details TBD.  (I think I've mentioned this idea loosely
before, probably on IRC.)  FWIW, I'm definitely not going to
code up this until I've changed over the CRIS port (done, but
with horrible pattern explosion and code size and performance
regressions; the latter solvable bug fixes to general gcc
parts).  It seems it's surely needed.

I also see a need that can be fulfilled by making the RTL
reader (at least when expanding these iterator macros) accept
and fold parallels with explicit "nil"s, so you can generate and
match non-clobbering variants too:
(define_code_macro (CCpart x)
  [(clobber CC_REG) (set CC_REG (compare:CC x (const_int 0)) nil])
causing the use:
 (parallel [(set op0 op1) (CCpart x)])
i.e. when expanded:
 (parallel [(set op0 op1) nil)])
fold to just:
 (set op0 op1).

Hoping this lures someone into implementing this or something
better instead of something less useful. ;)

brgds, H-P


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