[PATCH] Fix store motion, revised PRE memory handling

[Daniel Berlin]

law@redhat.com writes:

>   In message < 87u20cesr3.fsf@cgsoftware.com >you write:
>  > > This is a somewhat large-ish.  Would you split out the stupidity
>  > > killing into a separate patch?  It would make it easier to examine
>  > > the actual logic changes you've got in there.
>  > 
>  > Sure.
>  > I've attached the first patch (the stupidity killing).
>  > Speaking of logic changes, if we use !rtx_addr_varies_p when picking
>  > out candidate stores, do we still need to bother to see if the
>  > register operands change in various blocks?  If the address doesn't
>  > vary, doesn't it mean they couldn't be possibly changing in a
>  > meaningful way, because if they did, it would vary?
>  > 
>  > (We used to use rtx_varies_p, which was overkill, and would disqualify
>  > basically everything).
> Just so I'm 100% certain I understand what's going on here.
> 
> This patch removes the handling of loads during the normal pre phase
> under the assumption that we'll deal with all PRE redundant loads
> during the separate load-store motion phase.  Right?

No.
It removes redundant, more conservative tests, that were being
performed *after* we did a real depdendence test to determine if a load
was killed in a block.

We used to have simple mem handling, and any time a mem was set in a
block, we killed all the mems in the block.

Load motion to PRE changed this, such that we actually used true_dependence
to determine whether a given load was really killed in a given block
or not.

However, in what appears to be a botched cvs merge of some kind, both
tests appear.

So you have

if (<test using true_dependence to determine if the load is killed in
the block>)

followed by

if (<test using "is any mem set in a block">)

Which makes no sense at all, and is preventing load motion from really
working.


> 
> jeff

-- 
"I'm so hyper...  (Said with a very dull voice.)
"-Steven Wright