GCSE botch with EH case

[Daniel Berlin]

>
> 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