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