This is the mail archive of the gcc-bugs@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]

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67443

--- Comment #15 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
The original problem was that a 4-byte load (or whatever) from memory M into an
8-byte-register on bigendian machines is represented by a memory reference of
size 8 starting at M-4?  This problem was present since 138bc75d-0d04-0410-96
was applied, but never triggered because there was another code path that
identified the alias.  With the get_addr-Patch that safety net is gone and that
now triggers the bug uin the old patch.

The mistake that patch seems to make is to assume that a negative MEM_OFFEST
always indicates a "promoted subreg on" a "bigendian target" while there are
actually other situations where this can occur:

(1) Store a byte at address p; address p is loaded into register r<n> first.
(2) Some code forces register r<n> to be reused for other purposes.
(3) Load address p to a register r<m>; r<n> is still used by something else.
(4) Read bytes 1-2 (or more) from address p+1; this results in a multi-byte
read from address p; p is loaded into register r<m> (m != n) because r<n> is
still in use.

Changing the condition to

  if (MEM_OFFSET (mem) < 0
      && (MEM_SIZE (mem) + MEM_OFFSET (mem)) * BITS_PER_UNIT == ref->size
      && MEM_SIZE (mem) + MEM_OFFSET (mem) > 0
      && (-MEM_OFFSET (mem)) % (MEM_SIZE (mem) + MEM_OFFSET (mem)) == 0)
   return true;

fixes that (but possibly causes problems elsewhere).  The changed code just
assumes that "aligned" (-offset == size / 2, probably should take the memory
addres into account) references with negative offset are are caused by
"promoted subregs on bigendian targets" and "unaligned" references are not. 
It's in no way obvious to me whether this "unaligned" check covers exactly all
relevant cases.  Probably not, but at least it makes the test program work.


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