[PATCH] Make extra_order_size_table effective on targets with MAX_ALIGNMENT > 4

Mark Mitchell mark@codesourcery.com
Wed Jun 21 19:39:00 GMT 2006


Richard Guenther wrote:

> !       /* Build an alignment mask we can use for testing
> !          size % 2*align.  */

Why 2*align?

I find this code very confusing.  Let's see if we can clear it up.  I
might be very dense, but maybe the next person will be too.

!       /* Walk until we find a smaller bin with same or better
alignment.  */

How about:

  /* All objects smaller than the OBJECT_SIZE for this ORDER could go
into ORDER.  Determine the cases for which that is profitable.  */

For this:

! 	  unsigned int old_sz = OBJECT_SIZE (size_lookup [i]);
! 	  if (!(old_sz & (align >> 1))
! 	      && old_sz < OBJECT_SIZE (order))
! 	    break;

why not just if "(old_sz >= OBJECT_SIZE (order)) break;"?  Is the point
that even though an object of size I might be in some smaller order, an
object of size J < I might be in a bigger order, due to alignment
constraints?   How can that be?

! 	  /* Do not touch lookup entries which represent bigger
! 	     alignment than what we provide and do not override
! 	     smaller bins.  */

/* If object of size I are presently using a larger bin, we would like
to move them to ORDER.  However, we can only do that if we can be sure
they will be properly aligned.  They will be properly aligned if either
the ORDER bin is maximally aligned, or if objects of size I cannot be
more strictly aligned than the alignment of this order.  */

  if (old_sz > OBJECT_SIZE (order)
      && ((i & align) || !(OBJECT_SIZE ...))

But, why is the check for MAX_ALIGNMENT required here; you've already
masked higher bits out of ALIGN above?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713



More information about the Gcc-patches mailing list