https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125728
Andrew DeRosier <andy at skychase dot zone> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andy at skychase dot zone
--- Comment #6 from Andrew DeRosier <andy at skychase dot zone> ---
Made an attempt at fixing it, in gcc/rtlhooks.cc:
@@ -115,6 +115,9 @@ gen_lowpart_if_possible (machine_mode mode, rtx x)
else if (MEM_P (x))
{
/* This is the only other case we handle. */
+ if (paradoxical_subreg_p (mode, GET_MODE (x)))
+ return 0;
+
poly_int64 offset = byte_lowpart_offset (mode, GET_MODE (x));
rtx new_rtx = adjust_address_nv (x, mode, offset);
if (! memory_address_addr_space_p (mode, XEXP (new_rtx, 0),
gen_lowpart_for_combine seems to do something similar in its MEM_P branch
(returns SUBREG).
The odd-addressed and.b doesn't get widened anymore in the project where I
encountered the issue. Since the change isn't m68k specific I'm concerned about
the blast radius. Happy to test it on others, just want to run it by somebody
with a more intimate understanding of rtl optimizations first.
Probably the biggest thing I'm not sure of here, is letting a paradoxical
lowpart of a MEM widen ever "good" even on little endian targets?
