https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
--- Comment #60 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, I suppose
lduh [%g3], %g4 ! MEM[base: ptr_110, offset: 0B], min_line
is not an instruction that works with unaligned %g3.
;; min_line_106 = (int) _215;
(insn 921 920 922 (set (reg:HI 482)
(mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2
A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1
(nil))
a (mem:HI ...) with A8. I wonder if we should ICE somewhere if such kind
of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform?
The TARGET_MEM_REF is created via
#0 create_mem_ref_raw (type=type@entry=0x7ffff5401000,
alias_ptr_type=alias_ptr_type@entry=<pointer_type 0x7ffff61e3c78>,
addr=addr@entry=0x7fffffffd560, verify=verify@entry=true)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:401
#1 0x0000000000c3b464 in create_mem_ref (gsi=gsi@entry=0x7fffffffd600,
type=<integer_type 0x7ffff5401000 short unsigned int>,
addr=addr@entry=0x7fffffffd640,
alias_ptr_type=<pointer_type 0x7ffff61e3c78>,
iv_cand=iv_cand@entry=<ssa_name 0x7ffff66cc948>,
base_hint=base_hint@entry=<ssa_name 0x7ffff66cc948>,
speed=speed@entry=true)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:721
#2 0x0000000000c96f9a in rewrite_use_address (use=use@entry=0x18b8a10,
cand=cand@entry=0x1a26f50, data=<optimized out>, data=<optimized out>)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6471
#3 0x0000000000c97513 in rewrite_use (cand=0x1a26f50, use=0x18b8a10,
data=0x7fffffffd9c0)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6539
#4 rewrite_uses (data=data@entry=0x7fffffffd9c0)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6568
#5 0x0000000000c9cb35 in tree_ssa_iv_optimize_loop (loop=<optimized out>,
data=0x7fffffffd9c0)
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6894
#6 tree_ssa_iv_optimize ()
at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6926
Ah, so the issue is that may_be_unaligned does
1706 unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
1707
1708 unsigned HOST_WIDE_INT bitpos;
1709 unsigned int ref_align;
1710 get_object_alignment_1 (ref, &ref_align, &bitpos);
1711 if (ref_align < align
1712 || (bitpos % align) != 0
1713 || (bitpos % BITS_PER_UNIT) != 0)
1714 return true;
thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_
mode alignment which is what matters on STRICT_ALIGNMENT targets.
Fix:
Index: gcc/tree-ssa-loop-ivopts.c
===================================================================
--- gcc/tree-ssa-loop-ivopts.c (revision 213050)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step)
return false;
unsigned int align = TYPE_ALIGN (TREE_TYPE (ref));
+ if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align)
+ align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref)));
unsigned HOST_WIDE_INT bitpos;
unsigned int ref_align;
can you test and apply that patch?
Thx.
With that patch I get
ldub [%g3+1], %g2 ! MEM[(unsigned char *)ptr_110], MEM[(unsigned
char *)ptr_110]
ldub [%g3], %g1 ! MEM[(unsigned char *)ptr_110], MEM[(unsigned
char *)ptr_110]
sll %g1, 8, %g1 ! MEM[(unsigned char *)ptr_110],, tmp462
or %g2, %g1, %g1 ! MEM[(unsigned char *)ptr_110], tmp462,
min_line
