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: Changing the treatment of the MIPS HI and LO registers


"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>> >  Is there absolutely no way to preserve the current asm semantics without
>> > complicating the internals horribly?  I could imagine GCC could use some
>> > other constraints internally that would refer to the HI and LO registers
>> > explicitly and "h" and "l" could only be defined for asms -- I am not
>> > enough of a GCC expert here, so I don't know if it makes sense, but it
>> > would seem a reasonable idea to me.
>> 
>> I just don't think there is, sorry.  If you have:
>> 
>>    asm (... : "=h" (word1), "=l" (word2) : ...);
>> 
>> then there needs to be at least two separately-allocatable registers,
>> each of which can hold word-sized values.  And if we have two such
>> registers, the allocators will think they can use them for other things,
>> including spill space.  Which brings us back to where we are now.
>
>  I have just been wondering whether these can be defined as aliases to
> halves of the "x" register or something like that.  Not as real registers
> seen by the allocator.

The construct:

    "=<class>" (value)

says "find me a free register in class <class> that can hold <value>".
<value> itself might not be allocated to a register in <class>;
if it isn't, reload will find a spare register R in <class>,
use it as the operand, then copy R to <value>.

The registers available for reloads are also those seen by the
register allocators.  Hence the alternative I mentioned in the
snipped part of the message: having a hook that restricts the
allocation of certain registers (in this case HI) so that they
are still free for reloads but cannot be used in certain other
circumstances.

I think you're suggesting that "=h" and "=l" together form
a reload request for a single doubleword register.  I think that
would be even more complicated.  Reload has no support for two output
alternatives that assign to the same register (with an one-the-side
note saying that one operand assigns to one half and the other operand
assigns to the other half).  Such a thing is really counter to the
way GCC models registers.

Richard


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