This is the mail archive of the gcc@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: subreg:HI of PSI HW register issue


09/03/2012 17:10, Bernd Schmidt:
> On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
>> I'm not used to work at tree level for now and it is unclear for me what
>> part of the code should be tweaked. Can you tell me which part of the
>> code you are fixing/looking at, so that I can have a better
>> understanding of ptr_mode vs Pmode before your fix?
> 
> I'm thinking the bitfield code in expmed.c (extract_bit_field_1 etc.)
> needs a subreg_offset_representable_p check, followed by looking for the
> next larger integer mode if that fails. Then, if necessary, cast the
> result back to the original mode in case of extraction.
> 
> 
> Bernd


I'm working on a fix for this issue in store_bit_field_1, but it is not
possible to know by advance if a pseudo register in PSI mode will be
reloaded into a register which will have all its word_mode subregs
representable.

So if the problem is not addressed during reload, it seems the only
solution is to force both extract and store operations on pointers into
integer mode if Pmode is a MODE_PARTIAL_INTEGER.

I did a quick fix for my target for the store operations in
store_bit_field_1, but I wonder if this is the right place to fix it
(e.g when defining the assignment type in the tree?).
Any advice?


There is another point which makes me confused about ptr_mode. I thought
ptr_mode was the integer mode which would contain Pmode (So SImode if
Pmode=PSI). But it is defined in the same class than Pmode
(MODE_PARTIAL_INTEGER here). So for my target, the ptr_mode is the same
as Pmode. So why making a difference between Pmode and ptr_mode ?



Aurélien


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