This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCSE botch with EH case
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 14 Aug 2004 11:14:56 -0400
- Subject: Re: GCSE botch with EH case
- References: <10408141433.AA20756@vlsi1.ultra.nyu.edu>
If I look at .07.gcse, I see:
STORE_MOTION delete insn in BB 12:
(insn 109 185 215 12 (set (mem/s/j:SI (plus:DI (reg/f:DI 20
frame)
(const_int -32 [0xffffffffffffffe0])) [16
FRAME.59.i+0 S4 A128])
(reg:SI 102)) 43 {*movsi_1_nointernunit} (nil)
(nil))
STORE MOTION replaced with insn:
(insn 215 109 111 12 (set (reg:SI 108)
(reg:SI 102)) -1 (nil)
(nil))
STORE_MOTION insert store at start of BB 14:
(insn 216 209 207 14 (set (mem/s/j:SI (plus:DI (reg/f:DI 20 frame)
(const_int -32 [0xffffffffffffffe0])) [16
FRAME.59.i+0 S4 A128])
(reg:SI 108)) -1 (nil)
(nil))
That makes no sense and is the source of the problem. The issue is
that
the edges it's looking at are abnormal edges, so it's creating a store
in
the EH case that wasn't there in the the normal case. I don't at all
understand what this store motion is all about. Not only does it
appear
incorrect, but I don't see how it's an "optimization".
This i'll ignore, since i'm really not up to explaining the details of
store motion to you right now, when any compiler book could do it just
as well.
I'm at a complete loss to understand this, which looks like it's
causing
the remaining ACATS failures.
Is this on a clean tree? One with local patches? If it's one with
local patches, please retry this on a clean tree and let us know if
it's still happening.
It looks like some code that handles this in compute_pre_data needs to
be added to build_store_vectors, but it also could be some local
patches in your tree.
--Dan