Size changes, round 1

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    >> I'm certainly willing to believe that the same rationales that
    >> caused the introduction of TYPE_SIZE_UNIT would apply here as
    >> well.

    Richard> Probably not.  The rationale behind adding TYPE_SIZE_UNIT
    Richard> is that Fortran got lots of extra divides thrown into the
    Richard> insn stream because the backend saw ((N*8)/8) instead of
    Richard> N when dealing with multidimensional variable-sized
    Richard> arrays.

    Richard> Natually, the *8 and /8 didn't show up in the same place,
    Richard> otherwise we could have fixed this in constant folding
    Richard> somewhere.

    Richard> That's not to say that there's no reason to clean up DECL
    Richard> or to make things consistent, but the reasons behind
    Richard> TYPE_SIZE_UNIT were much more practical and immediate.

But, in fact, your point of view would seem to argue against adding
more _SIZE_UNIT fields in that the real problem here was in GCC's
optimizer, right?  With better analysis, wouldn't we have been able to
fold out the multiplies and divides? 

Sometimes, of course, it's better to do a little hack, and reap
immediate benefits, than develop some grand new optimization.  So, I'm
not criticizing.  But, if better optimization will obviate then need
for TYPE_SIZE_UNIT, then I'm not sure we should be pushing this stuff
further into the compiler.

Of course, my ADT suggestion allows us to defer that decision.  We can
always simply change the ADT to reprsent a size with just SIZE, and
not SIZE_UNIT, someday later.  In other words, we can have the
consistency benefits now -- but without making it any harder to go
back to a simpler representation later.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com