Serious performance regression -- some tree optimizer questions
Ulrich Weigand
Ulrich.Weigand@de.ibm.com
Tue Dec 21 23:39:00 GMT 2004
Paul Schlie <schlie@comcast.net> wrote on 12/21/2004 11:00:21 PM:
> 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))))
This appears somewhat of a mixture of RTL and tree syntax ;-)
In any case, both tree and RTL never allow implicit type changes, i.e.
all operands and the result of any operation (except the extend and
truncate operations, of course) have always the same type/mode.
[snip]
> 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.
Since GCC has quite a lot of code to perform this very type of
optimization,
I'm not quite sure what you're getting at. Are there some instances where
we still miss such an optimization? If so, it would be helpful to discuss
a specific example ...
All this is in any case irrelevant to the topic of this thread ;-)
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com
More information about the Gcc
mailing list