mn10300-elf reload problem (enabled by subreg byte?)

Andrew Macleod amacleod@cygnus.com
Mon Apr 9 07:01:00 GMT 2001


>> While building mn10300-elf's libstdc++-v3 (main multilib variant)
>> after the SUBREG_BYTE patch went it, subreg_hard_regno(), as called by
>> alter_subreg_regno(), would abort() in the following insn:
>> 
>> (set (reg:QI d1) (subreg:QI (reg:SI a3)))
>> 
>> because HARD_REGNO_MODE_OK is false for a3 and QImode unless
>> TARGET_AM33.
>> 
>> The pseudo that was assigned to a3 had many uses in SImode, so, even
>> though its preferred class was DATA_REGS, the alternate register class
>> was DATA_OR_ADDRESS_REGS.  Presumably, REGISTER_MOVE_COST could be
>> increased between DATA_REGS and other classes when moving subword
>> modes, but it would probably still be possible to construct a case in
>> which global alloc would assign such a pseudo to an address register,
>> and reload would have to fix it up.
>> 
>> Here's a patch that arranges for reload to detect the invalid hard
>> register use within the SUBREG, and push a reload so that it's fixed
>> up.  With this patch, mn10300-elf builds libstdc++-v3 to completion.
>> Ok to install?


Good, I was looking at this exact thing, albeit on a different
port... It is indeed triggered by the subreg byte patch. One less 
thing for me to deal with now :-)


Andrew



More information about the Gcc-patches mailing list