> > 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 your claim of "serious problems".
> We knew what we were doing when we made it, and we knew it would have
> some issues that would take further disambiguation to solve.
> This just happens to be one of those cases.
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 something like:
struct X {int i; unsigned int iu; short s; unsigned short us;} x;
and then you have x.i as a reference someplace and you need to know
what it conflicts with. The RTL pass correctly assigns this the alias
set corresponding to "int". From what I'm reading here, the tree optimizers
assign this the alias set corresponding to "struct X". That means that x.i
will conflict not just with accesses to int, but to unsigned int, short,
and unsigned short as well. That's wrong and unnecessary and I don't
understand how fixing this will cost memory.
This is hardly a pathalogical corner case that it's OK to get wrong. This
is the *central case* around which much of the aliasing system has been
designed. I don't believe that getting this wrong is reasonable.
