RFA [PR rtl-optimization/37273] [4.4/4.5/4.6 Regression] IRA does not re-materializes addresses (loads from the TOC)

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is the analysis for pr 47464, which was triggered by my change for
pr 37273:



ifcvt thinks the memory reference in insn 69 is safe to move because it
is marked as notrap....  That's obviously incorrect.

The marking as notrap occurs due to an interesting sequence of events.
First we have a pseudo (83) which is set once from a MEM (with a varying
address) and used once:

(insn 27 26 28 3 (set (reg:SI 83 [ MEM[(const struct VEC_tree_base
*)D.17991_13].num ])
        (mem/s:SI (reg/f:DI 71 [ D.17991 ]) [6 MEM[(const struct
VEC_tree_base *)D.17991_13].num+0 S4 A64])) j.c:7464 64 {*movsi_internal}
     (nil))

(insn 28 27 65 3 (parallel [
            (set (reg/v:SI 75 [ ix ])
                (plus:SI (reg:SI 83 [ MEM[(const struct VEC_tree_base
*)D.17991_13].num ])
                    (const_int -1 [0xffffffffffffffff])))
            (clobber (reg:CC 17 flags))
        ]) j.c:7464 252 {*addsi_1}
     (expr_list:REG_DEAD (reg:SI 83 [ MEM[(const struct VEC_tree_base
*)D.17991_13].num ])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (expr_list:REG_EQUAL (plus:SI (mem/s:SI (reg/f:DI 71 [
D.17991 ]) [6 MEM[(const struct VEC_tree_base *)D.17991_13].num+0 S4 A64])
                    (const_int -1 [0xffffffffffffffff]))
                (nil)))))



ira.c::update_equiv_regs attaches a REG_EQUIV note to insn 27.  This is
the first place where I started to question the compiler's correctness.
 Based on my reading of REG_EQUIV, it's correct.  It would be valid
(from a dataflow standpoint) to replace every occurrence of (reg:SI 83)
with (mem:SI (reg:DI 71)).  So the REG_EQUIV seems appropriate.

IRA decides that (reg:SI 83) is best left in memory.  A reasonable
choice.  Reload also decides to leave it in memory and replace the
pseudo with its equivalent memory location.  In that code reload sets
the MEM_NOTRAP_P bit for the equivalent memory location.  This is the
point at which I believe things have gone wrong.

Anyway, later ifcvt looks as the MEM_NOTRAP_P flag and decides it can
move the memory reference with abandon and moves the memory reference
before the address check guard triggering the fault.

As I mentioned, I believe the point at which we've taken the wrong step
is setting MEM_NOTRAP_P.  While it is true that the memref can't trap as
long as it stays in its original context, ifcvt can change the context
in which the MEM occurs thus making MEM_NOTRAP_P inconsistent with reality.

So I think we've got two approaches to fix this problem.  First we can
avoid setting MEM_NOTRAP_P so aggressively in reload.  Or we can change
ifcvt to not move MEM_NOTRAP_P insns so aggressively.  I'm going to
attempt the first approach.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNP7gbAAoJEBRtltQi2kC7wxkIAIzodL3M5JtVCALjlAe5CM3k
rhapjZ9eyQHYZpN1JVRhKWk0ECqb9+PyOjtgk2bo9HVPT9oJsOhGzdx3rRMYgOth
k7crkaFqxBodSHiC/BamnH4jCjnSz5VZ4D/WCqHtPpzroZR/tADGRJJhLdAl/jqv
+zHnmnpVs2JIXB41LMkgESETcHvzSoVOQtjxo75S3z+Bsa8PUA8PCEZEGPXHuKB4
07RmBfYX/kKygO7QGZt9+jp87iRo/bizT9EWh886LG1uxOptYoem4scoZBsPZR+g
tQKMqokN9qe8f5EHdxO7+JbnmIgFd6BE8b3rRPmlbVWH09B/dOQeHNSjAy0BXLo=
=B5Rm
-----END PGP SIGNATURE-----