This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: slot combination and alias analysis


> Date: Sat, 6 Oct 01 07:09:08 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: mrs@windriver.com
> Cc: gcc@gcc.gnu.org

> But the code later in the function handles the case where one type is
> unknown and, I think, does it correctly.

Yes, this is what I thought at the start of yesterday too.  Then I
investigated the code.  I don't hold that opinion anymore.

You have two function bodies.  In one, it does { float f; ... }, in
the other, it does { double d; ... }, they reference at least one byte
in common through the magic of inlining.  The optimizer knows that
they don't conflict, but the stack frame code just allocates a block
(unknown), and then uses it.  Unfortunately, one of the uses can be
known, say the first float.  In the second, instead of being just an
unknown block, the memory is used as a known double.  Since a known
float and a known double can never conflict, we know we can reorder
the memory references.  But, we see that this would be wrong.  I
already said that the memory blocks allocated overlap.  Hence, we must
go out of our way, to ensure they never conflict:

!   /* The alias set for the slot.  If the alias set is zero, we don't
!      know anything about the alias set of the slot.  We must only
!      reuse a slot if it is assigned an object of the same alias set.
!      Otherwise, the rest of the compiler may assume that the new use
!      of the slot cannot alias the old use of the slot, which is
!      false.  If the slot has alias set zero, then we can't reuse the
!      slot at all, since we have no idea what alias set may have been
!      imposed on the memory.  For example, if the stack slot is the
!      call frame for an inline functioned, we have no idea what alias
!      sets will be assigned to various pieces of the call frame.  */

>From the original wording, before your change.  I think I now
understand what Mark meant.  His use of the term alias set 0 is
unfortunate.  -1 would be closer, or maybe -2.  0 already had a
meaning, and it means that you will never have to worry about this
memory and other memory conflicting.  But, in our case, it is a we
can't know, and further, someone else may have assigned any alias set
for the memory and used it in that fashion.  This goes well beyond an
alias set 0 use.

This is in part why I asked about the subset/superset stuff.  That
would be fairly coarse, but would be better than no reuse.  Better,
would be an aggregate scheme.  I think the semantics we may want
exactly match the new code that you put in.

Mark, is my understanding of why you had that code correct?  Do you
see any reason why we could do what kenner did?  I don't think we can,
as a local use of a float can overlap the use of a float in an inline
function body, and one of them would be known, and the other unknown,
and the current code would reuse the slot.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]