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: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, 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 10:42:29 +0100
- 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> <20150422072758 dot GF23315 at gate dot crashing dot org>
On 22/04/15 08:27, Segher Boessenkool wrote:
> 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
> 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?
Scratches are often the consequence of RTL semantics not exactly
matching the machine's real instructions (or an RTL pattern needing to
expand into more than one real instruction). Getting rid of them would
imply making GCC's RTL more exactly represent the semantics of each
machine. That might be feasible for some architectures but is likely to
be quite hard for others. Eliminating them would, IMO, require a fairly
major change to the semantics (and cross-platform neutrality) of RTL.