[RFA]: Fix reload of paradoxical subreg on big-endian platforms when reg is in memory

[Stephane Carrez]

Hi!

Jan Hubicka wrote:
>>Hi!
>>
>>Jan Hubicka wrote:
>>
>>>>Hi!
>>>>
>>>>I've found a reload problem with paradoxical subregs on big-endian 
>>>>platforms.
>>>>When a register is in memory and its paradoxical subreg is reloaded, we
>>>>compute its address but we come up with a wrong address representing the
>>>>high part instead of the low part.  It is a regression compared to 3.0.4.
>>>
>>>
>>>It seems to be that it is invlid to reload paradoxical memory subreg
>>>without reloading the inner value first, because we may access
>>>unintialized or missaligned memory.  Perhaps reload_inner_reg_of_subreg
>>>needs extra check?
>>>
>>>Honza
>>>
>>
>>No because reload_inner_reg_of_subreg() is called only from 
>>push_reload()/combine_reloads()
>>and it's too late.  It can only deal with a hard reg not in the good class.
>>
>>The register is in memory (reg_equiv_memory_loc[regno] != 0) and 
>>find_reloads_toplev
>>together with find_reloads_subreg_address will reload that memory rtx.
> 
> 
> Then I believe that find_reloads_subreg_address is wrong here because we
> result in wrong memory access.  Other palce, like combiner or

Yes; this is what my patch fixes


> reload_inner_reg_of_subreg special case this.  One simply can elliminat
> paradoxical subreg on memory.
> In fact I do have separate patch for subreg in addresses reloading in
> the queue.  Perhaps it is the answer to your testcase too?
> http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00379.html
> It was designed for different problem, but the code in question should
> deal correctly with paradoxical subregs as well.
> 
It does not solve it because find_reloads_subreg_address() is called from
find_reloads_toplev() (near lines 4504) but your patch fixes a subreg problem in
find_reloads_address_1(). FYI, backtract when pb occurs

#0  find_reloads_subreg_address (x=0x401c2918, force_replace=1, opnum=1,
     type=RELOAD_FOR_INPUT_ADDRESS, ind_levels=0, insn=0x401c52ec) at reload.c:5882
#1  0x081828f7 in find_reloads_toplev (x=0x401c2918, opnum=1, type=RELOAD_FOR_INPUT_ADDRESS,
     ind_levels=0, is_set_dest=0, insn=0x401c52ec, address_reloaded=0xbfffeda4) at reload.c:4504
#2  0x0817db26 in find_reloads (insn=0x401c52ec, replace=0, ind_levels=0, live_known=1,
     reload_reg_p=0x8352740) at reload.c:2708

In my case find_reloads_address_1() is called on the memory location (with wrong offset)
and not on the SUBREG (which your patch manages).

	Stephane