This is the mail archive of the 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 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
>> 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

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.


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