Re: Storing 16bit values in upper part of 32bit registers

[Markus L <markusl dot se78 at gmail dot com>]

This is actually what I ended up doing. Currently this approach seems
to have way less drawbacks than my original way of doing this.. so I
cant say that I've found anything wrong with it yet :)

2009/11/6 H. Peter Anvin <hpa@zytor.com>:
> On 10/15/2009 08:56 AM, Richard Henderson wrote:
>> On 10/15/2009 07:41 AM, Markus L wrote:
>>> However the IS is designed so that it is beneficial to to store 16bit
>>> values in the high part of the registers (rNh) and also the calling
>>> conventions that we want follow require 16bit values to be passed and
>>> returned in rNh.
>>>
>>> What would be the "proper way" make the compiler use the upper parts
>>> of these registers for the 16bit operands?
>>
>> This feature is going to be difficult, but not impossible, and unless
>> your ISA has some really odd features I won't vouch for the code quality.
>>
>> You say you want to canonically represent HImode in the high-part of the
>> register. ?Additionally, you'll have to represent QImode in the
>> high-part (if not further in the high byte).
>>
>> You'll need to follow the mips port and define TRULY_NOOP_TRUNCATION and
>> the associated truncMN2 patterns.
>>
>> If you do all this, you won't have to do anything with FUNCTION_VALUE
>> etc at all.
>>
>
> Sorry for a *way* *late* reply to this, but wouldn't it also work to
> model the register file as a set of 16-bit registers (since that's what
> you really have -- individually addressable 16-bit registers) and
> exclude SImode values from register pairs which are not aligned. ?Then
> one can simply prefer the high 16-bit registers to the low 16-bit
> registers in the register priority sequence.
>
> I'm assuming there is something wrong with this, but I'm kind of curious
> as to what it would be.
>
> ? ? ? ?-hpa
>