Re: [PATCH] Fix optimization regression in constant folder

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 11 Oct 2007, Richard Kenner wrote:

> > "these properties" are those which you and Eric expected sizetype to have, 
> > and where we then had this very thread to actually try and spell out the 
> > properties, i.e. those properties which you initially "defined" as "all 
> > optimizations are allowed".  
> 
> One can argue about what those properties ought to be, but they clearly 
> have *some* properties!

Of course.  I think "unsigned, wrapping overflow" are these properties, 
hence no need for a special sizetypiness.

> And there's no particular reason to believe those should match those of 
> any user-visible type, since they are used in very different ways than 
> any user-visible type.

Please, don't go that route again.  I'm not talking about user-visible 
types.  I never was.  I'm talking about the properties of sizetype (the 
global tree node), and I'm arguing that it simply should be an unsigned 
integer type without other special properties.  Don't repeat the argument 
of Ada needing negative values there, I think it's a red herring as  
negative values can be represented in unsigned types just fine, it's just 
a matter of interpreting it correctly.

> Being able to *show* a test case and *having* one aren't the same!  The 
> problem here is that it's only going to occur in large programs and 
> those are proprietary.  It's a lot of work to sanitize such a large test 
> case. Conceptually, it's easy to describe: we're talking about records 
> where there are a large number of variable-length arrays, some of which 
> have the same index and some of which do not, and we're trying to 
> simplify the computation of the offset of the later fields ni the 
> record.

Okay, so conceptually it's like:

struct S {
  int a1[n1*n2];
  int a2[n2*n1];
  int a3[n3];
} s;  /* so a1 and a2 have the same number of elements */

And then you access this in e.g. such way:

for (i = start; i <= end; i++)
  use (s.a1[i], s.a2[i+2], s.a3[i]);

And you of course want that the necessary index calculations are done as 
optimally as possible, i.e. that the three expressions (i), 
((i+1)+(n1*n2)) and (i+(n1*n2)+(n2*n1)) are optimized.  Would that be 
a correct description of the situation (I'm assuming it's more complicated 
of course)?


Ciao,
Michael.