This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LRA unaligned reloads


On 12-11-03 9:37 PM, David Miller wrote:
On 32-bit sparc with LRA enabled we have the following (this
generated for gcc.dg/vect/pr51581-4.c with -flto):

(insn 252 142 165 4 (set (reg:HI 234 [ D.1511 ])
         (mem/c:HI (plus:SI (reg/f:SI 1307)
                 (const_int 24 [0x18])) [4 b+24 S2 A64])) test.c:23 59 {*movhi_insn}
      (expr_list:REG_EQUIV (mem/c:HI (plus:SI (reg/f:SI 1307)
                 (const_int 24 [0x18])) [4 b+24 S2 A64])
         (expr_list:REG_EQUAL (mem/c:HI (const:SI (plus:SI (symbol_ref:SI ("b.1425") [flags 0x2]  <\
var_decl 0xf7519740 b>)
                         (const_int 24 [0x18]))) [4 b+24 S2 A64])
             (nil))))

...

(insn 255 221 233 4 (set (reg:SI 1285)
         (ashift:SI (subreg:SI (reg:HI 234 [ D.1511 ]) 0)
             (const_int 16 [0x10]))) test.c:23 306 {ashlsi3}
      (expr_list:REG_DEAD (reg:HI 234 [ D.1511 ])
         (nil)))

When LRA does reloads for insn 255, it tries to strip the subregs
for pseudo 234 and use SImode moves.

(insn 1367 1732 1712 4 (set (reg:SI 12 %o4 [1425])
         (mem/c:SI (plus:SI (reg/f:SI 3 %g3 [1307])
                 (const_int 22 [0x16])) [4 b+22 S4 A16])) test.c:23 61 {*movsi_insn}
      (nil))
(insn 255 1712 1366 4 (set (reg:SI 12 %o4 [1285])
         (ashift:SI (reg:SI 12 %o4 [1425])
             (const_int 16 [0x10]))) test.c:23 306 {ashlsi3}
      (expr_list:REG_DEAD (reg:SI 12 %o4 [1425])
         (nil)))
(insn 1366 255 1711 4 (set (reg:SI 12 %o4 [1285])
         (reg:SI 12 %o4 [1285])) test.c:23 61 {*movsi_insn}
      (expr_list:REG_DEAD (reg:SI 12 %o4 [1285])
         (nil)))

Unfortunately, this is illegal, because insn 1367 is an SImode
load to a non-4-byte-aligned location (%g3 + 22).

This does work, and might even be profitable, on non-STRICT_ALIGNMENT
targets.  But for those which are STRICT_ALIGNMENT, we cannot make
transformations like this.

David, thanks for reporting this. LRA has a code dealing with unaligned memory. And this code worked for targets which require aligned memory accesses. It seems that it does not cover all cases. I'll look at this bug although I don't know when exactly (I have still a lot of LRA PRs).



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]