This is the mail archive of the
mailing list for the GCC project.
Re: PR63633: May middle-end come up width hard regs for insn expanders?
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Georg-Johann Lay <avr at gjlay dot de>, GCC Development <gcc at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Denis Chertykov <chertykov at gmail dot com>, Senthil Kumar Selvaraj <senthil_kumar dot selvaraj at atmel dot com>
- Date: Wed, 22 Apr 2015 02:27:58 -0500
- Subject: Re: PR63633: May middle-end come up width hard regs for insn expanders?
- Authentication-results: sourceware.org; auth=none
- References: <544A7CFA dot 700 at redhat dot com> <20141024162919 dot GL10376 at tucnak dot redhat dot com> <544A7EE5 dot 1040303 at redhat dot com> <544A984D dot 8080804 at gjlay dot de> <20141024182950 dot GQ10376 at tucnak dot redhat dot com> <5530D95F dot 3070603 at gjlay dot de> <55355D76 dot 9060500 at redhat dot com> <CABu31nNE9f_BYYWL2Wd2BS2Ei8HpU4xkpJOvmduv2PRZKxm_aw at mail dot gmail dot com> <20150421060414 dot GA5958 at gate dot crashing dot org> <55371BB5 dot 9050104 at redhat dot com>
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
> 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
> 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
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?