reload cse may delete loads it shouldn't

Alexandre Oliva aoliva@redhat.com
Tue Apr 15 08:55:00 GMT 2003


A function as simple as this will miscompile on mn10300-elf -mam33 -O2
-fno-force-mem.  A far more complex function might fail even without
-fno-force-mem, but it's tricky to force it into the right conditions,
so I can't tell for sure.

int k;
int f(int p, unsigned char *q) {
  int j = *q + 512;
  *q = k = j;
  return p / *q;
}

After greg, we have something like this:

(set (reg:SI d1) (plus:SI (reg:SI d1) (const_int 512)))

;; ...

(set (mem:QI (reg:SI a0)) (reg:QI d1)) ;; *q = /* k = */ j;

(set (reg:QI d1) (mem:QI (reg:SI a0))) ;; reload *q for...

(parallel [(set (reg:SI d0) (div:SI (reg:SI d0) (reg:SI d1)))
           (set (reg:SI d1) (mod:SI (reg:SI d0) (reg:SI d1)))])


The problem is that we assume that, after the store of d1 in *q,
loading it back won't modify the value in d1, so reload cse deletes
the (zero-extending) load, and we end up using the SImode register
that contains *q + 512, instead of just *q.

Ideally, we should be replacing the reload instruction with a simpler
zero-extension, but I still haven't figured out why we don't do this
on mn10300, even though we seem to do it on x86.  I suspect it has to
do with the absence of LOAD_EXTEND_OP on i386.h, but I still haven't
verified this assumption.

Anyway, this patch is meant to fix the correctness issue in reload
cse.  The idea of the patch is to record the mode in which a register
was set, and only drop a copy from the same equivalence class if it
has the same mode as the original set.  Copying any different mode may
alter the contents of the register, so we don't drop such a copy.

I'm still going to bootstrap this to check for correctness, but does
the idea sound sound? :-)

Ok to install if it bootstrap on athlon-pc-linux-gnu?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reload-cse-noop-move-mode.patch
Type: text/x-patch
Size: 6746 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20030415/ac7e3285/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


More information about the Gcc-patches mailing list