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: RTL sharing tester (for testing)


Jan Hubicka <jh@suse.cz> writes:
>> Richard Sandiford wrote:
>> >If every register in [regno_first, regno_last] was unused, flow would
>> >add a REG_UNUSED note for the REG created above.  If only some of those
>> >registers were unused, flow would add notes for the individual unused
>> >registers.  As I said on IRC yesterday, I'm not convinced the first
>> >behaviour was a good idea.  That REG might well be invalid (otherwise
>> >why have a SUBREG in the first place?) and it's better not to have
>> >invalid registers floating around.
>> 
>> I agree with everything in your analysis, except possibly this.  If the 
>> SUBREG is valid, then I see no way how the REG could be invalid.  Since 
>> flow used to do this, I prefer we keep the same behaviour.

AIUI, it isn't a requirement though.  If we insisted that the equivalent
REG be valid (in the HARD_REGNO_MODE_OK sense), then I don't see any
point in subregs of hard registers at all.  The validate_subreg case
for hard registers ought simply to be "return false".  But at the moment
it allows subregs in which the equivalent hard register is not valid in
the HARD_REGNO_MODE_OK sense, as long as we can "safely" determine the
range of registers it covers.

This is what is happening in he mipsel-linux-gnu case.  We had
(subreg:DI (reg:DF $f0)), where $f0 is valid for DFmode but not DImode.
(And it shouldn't be valid for DImode in this case; we don't have any
instructions that would make a DImode FPR useful.)

I agree it makes sense to forbid subregs of hard registers altogether,
including the MIPS one above (not least because I'm unconvinced how
"safe" the determination really is).  But that's going to be quite
a far-reaching change, and isn't something we can likely do in
a few days.  In the meantime, I think the patch really does match
the current rules.

> I also agree here, in general we should have REGs floating around
> subregs valid.  The presence of subreg would be here as a mere retyping
> or something.  It should not be that common as we take care to fold away
> subregs of hard regs in several places.  (in longer run we might go
> further and declare those foldable subregs invalid, not sure if it is
> helping much however)

I agree that there's no point in having SUBREGs when an equivalent REG
exists, and that we already try quite hard to avoid them.  Were the
SUBREGs that you found examples of ones we'd missed, or didn't they
reduce to a valid REG at all?

> Adding one big coumpound REG_UNUSED/REG_DEAD note for the whole register
> IMO should make difference for peephole2 pass that is doing mathching on
> them (I am not sure if any of peep2s in existence rely on multiword
> hardregs).

Well, I'm not sure we should have such subregs after reload, no.
Hopefully the code you mentioned should ensure that.  (The case
I'm dealing with is before reload FWIW.)

Richard


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