x86
Matthew Fluet
fluet@research.nj.nec.com
Thu, 17 Aug 2000 16:43:05 -0400 (EDT)
> Has anything been done to fix the assumption that syntactially distinct
> memory locations are distinct? This REALLY REALLY scares me. It isn't just
> that it is incorrect, it is that often one will be able to get away with it.
> Thus these bugs can remain hidden for a long time.
Not yet. I know what the fix should be --> in register allocation there
is a place where I do the following:
dst = def's of instruction
commit/kick-out any memory location in the register file that utilizes
(i.e., is built up from) anything in dst.
This is what ensures that things are on the stack before we do a push (or
at the right place in the heap before we move the frontier).
Now it should be
dst = def's of instruction
commit/kick-out any memory location in the register file that utilizes
anything in dst or anything which may-alias anything in dst; also
commit/kick-out any memory location which may-alias anything in dst and is
not equal to it's may-alias
Algorithmically, not a problem. The only issue is that right now I have
that everything may-alias everything else (and that would kill
performance). I'm going to need to associate more information with memory
locations so that I can write a reasonable may-alias function (or inherit
something from a higher IL). This is related to the fact that I have
three types of memory locations which represent 8 operand types from the
Machine IL, so there isn't a good inverse function; yet, it's at the
Machine IL that I have a better way of expressing what operands must not
alias other operands. It will take a little bit of thought, but I don't
think it is insurmountable; nor should it ruin performance if the
may-alias function is "tight" enough.