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

Re: GCSE botch with EH case



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



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