Re: Serious performance regression -- some tree optimizerquestions

[Paul Schlie <schlie at comcast dot net>]

> From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
>> I apologize if this comment is misplaced, but it seems that one of the
>> things that tree optimization seems not to be doing (which seems important,
>> and would seem to simplify the determination of expressions sensitivity to
>> overflow, etc.) is to identify the maximum precision actually required of
>> any operation/operand evaluation based on it's assigned destination's actual
>> precision requirement (as although expressions may overflow it's use may be
>> insensitive to it).
>> 
>> As it seems for example, given:
>> 
>>   (size-x)X = (size-y)Y (size-binop)BINOP (size-z)Z;
>> 
>> - (size-binop) need never be wider than the smaller of either: it's
>>   destination (size-x) requirement, or maximum result size of the binop
>>   with (size-y) and (size-z) operands.
>> 
>> - and corespondingly (size-y)X and (size-z)Y need never be literally
>>   promoted unless the target-machine's (size-binop) operation requires it,
>>   but may be logically demoted if exceeding the precision requirements of
>>   the operation as determined by it's destination precision requirements
>> 
>> In other words, determine precision / overflow sensitivities from the top
>> (the last assigned use) of the expression tree down, not the bottom up
>> without knowledge of the expressions true need? (where the same basic rules
>> may be applied during the initial construction of the tree as well).
> 
> can you please provide a concrete testcase? I probably do not understand
> correctly what you describe.

My thoughts/comment was based on that it appears that GCC builds a tree for:

  (char)c = (unsigned long)l + (short)s

As something like:

  (set:<char> (operand:<char> c)
      (plus:<long>
          (operand:<long> l)
          (sign-ext:<long> (operand:<short> s))))

Then when looking for potential optimizations, might look at the node
(plus:<long> ...) to see it if can transform it into something simpler
and in the process tends to be concerned maintaining/overflowing the
precision while transforming the originally specified expression,
although the expressions may not actually represent the minimal precision
required of the operation, which tends to be based on it's assigned need;
which seem largely due to the overly conservative construction of the tree
initially (it seems)?

Therefore it would appear that if the tree were constructed more precisely
based on the precision required by it's use:

  (set:<char> (operand:<char> c)
      (plus:<char>
          (operand:<long> l)
          (operand:<short> s)))

Then (plus:<char> ...) expression may be manipulated any way desired,
without regard to potential overflow, etc. as long as the expression
maintains the required precision of <char>; which may then also enable
further simplifications with this knowledge, as for example:

  (set:<char> (operand:<char> c)
      (plus:<char>
          (operand:<long> l)
          (constant:<short> 0xFF00)))

It would then be apparent that since (plus:<char> ...) only cares about
the lowest 8-bits of precision, which is not affected by the operation,
the expression may be transformed reliably into:

  (set:<char> (operand:<char> c)
      (sub-operand/reg:<char> l 0))

I realize that I may have misunderstood the context of the thread, but
it seemed related to this type of issue, which would tend to be of
greatest benefit to smaller targets, and/or small operand/operation
vectorization; as it would seem that constraining an expressions
representation to it's it's minimally required precision form, simplifies
both subsequent optimizations, as well as it's abililty to be mapped most
efficiently into it's minimally required precision form, while maintaining
it's correctness/compliance.

Thanks, and hope these thoughts aren't too far off topic, -paul-