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: PR63633: May middle-end come up width hard regs for insn expanders?


On Tue, Apr 21, 2015 at 11:55:33PM -0400, Vladimir Makarov wrote:
> >The combiner can add or remove clobbers of scratches whenever needed,
> >but it cannot do that for clobbers of pseudos.
> >
> Yes, I think there are some pitfalls with scratches in other passes.

Probably.  But this one is documented (under CLOBBER as well as
MATCH_SCRATCH) ;-)

> As for combiner, it is probably worth to consider processing clobbers of 
> pseudos with *one* reference as scratches too.

The combiner can already remove any clobber when it needs to (to pass
recog).  It cannot add a clobber of a pseudo -- making it do that
requires changing recog (and few lines in combine, if any).  Currently,
combine can add clobbers of scratches and hard regs, when recog tells
it to.  In the past combine could not handle any new registers (even
though it actually creates some), but Jakub's r220368 should take care
of that.

> It might improve code 
> for some cases although I am not sure about this.

I don't see how.  Maybe there is some sub-optimality in current code,
but that can be fixed of course.  The concept stays the same: a pseudo
that isn't used anywhere else, or a scratch.  Same thing, just expressed
differently.

Getting rid of match_scratch from the RTL passes before RA will be an
enormous amount of work, and it will not improve anything (quite the
opposite): every define_expand, define_insn, define_split and
define_insn_and_split that runs (or can run) before reload, and
currently has a match_scratch, will need to be modified.  We will need
extra expanders everywhere, to match the pattern without the new pseudo,
and add a new pseudo.  Then we could add some markup so we do not need
that, but we already *have* such markup: match_scratch.

I'm also not looking forward to checking all RTL passes for regressions.


In your last reply to Steven you say that IRA only wants match_scratch
with every alternative needed (not "X") to be a pseudo before IRA gets
to see it.  Can IRA not do this itself?


Segher


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