This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA]: Fix reload of paradoxical subreg on big-endian platformswhen reg is in memory
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