Hi,
On Tue, 8 Sep 2009, Alex Turjan wrote:
> (insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [19 fac_iter+0 S4 A32])
> (reg/v:SI 16 r16 [orig:161 step109 ] [161])) 48
> {si_indexed_store_incl_ra} (nil))
An SI store to a MEM of alias set 19 (and a non-trapping while we're at
it, the /c marker on the MEM) ...
> despite being consumed (in bb3) by the following 2 loads:
> (insn 380 71 64 3 test.c:112 (set (reg:HI 1 r1)
> (mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 96 [0x60])) [0 S2 A16])) 12 {load} (nil))
>
> (insn 382 346 65 3 test.c:112 (set (reg:HI 5 r5)
> (mem:HI (plus:PSI (reg/f:PSI 55 ptr15)
> (const_int 98 [0x62])) [0 S2 A16])) 12 {load} (nil))
... and two HI loads of MEMs of alias set 0. This should be fine as set 0
aliases with everything. Either you need to open a bugreport with
necessary patches to reproduce the above, or make it reproduce on trunk,
or you need to debug dse.c yourself.
There is one peculiarity about dse.c which might be able to help you in
determining the cause. dse.c operates under the assumption that all spill
slot accesses generated by reload are using exactly the same alias set and
that any such slot is completely unaliased by anything else including
stuff with alias set 0. This is done only by the after-reload dse pass.
See functions dse_record_singleton_alias_set and friends. Your loads
should kill the active stores in function check_mem_read_rtx should you
need to debug it that far.
My assumption would be these two split loads of HImode are generated by
your backend from a given SImode MEM. If so, you need to make sure to
copy the MEM_ALIAS_SET, at least for spill slots (better for everything)
into the newly generated HImode mems. For spill slots it's not enough to
set it to zero.
Ciao,
Michael.
