Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> > alias_sets_conflict_p() is used to determine if an addressable variable
> > and a type conflict also from the tree-ssa alias machinery (in effect to
> > determine which virtual variables need to be clobbered). It just isn't
> > feed COMPONENT_
> alias_sets_conflict_p() is used to determine if an addressable variable
> and a type conflict also from the tree-ssa alias machinery (in effect to
> determine which virtual variables need to be clobbered). It just isn't
> feed COMPONENT_REFs, that's what you found very wrong, and I explained
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> > The problem lies in the way how we represent load and store dependencies
> > as virtual operands. Conflicts between a pair of mem accesses are not
> > evaluated by asking alias_set_conflicts_p() on both accesses, but instead
> > via a chain of
> The problem lies in the way how we represent load and store dependencies
> as virtual operands. Conflicts between a pair of mem accesses are not
> evaluated by asking alias_set_conflicts_p() on both accesses, but instead
> via a chain of virtual def and use operands.
But I thought this who
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> I moved this to the main list because I think it's of general interest.
>
> I fail to understand how the issue of which alias set is used has any
> appreciable effect on the amount of memory used at compile time.
>
> The issue here is with somethi
> > But if it can't handle very simple cases correctly, I'd say it has some
> > serious problems.
>
> I await your design for a completely accurate def-use chain
> representation for memory accesses that does not take infinite amounts
> of memory at compile time.
> Until then, i have to laugh at
