We use zero_extend and sign_extend in two different circumstances. One is well
defined and one is conditionally undefined.
a) When extending a valid value in one representation to a valid value in a
longer representation. For instance when converting a short to a long. This is
well defined.
b) When truncating a possibly value from a longer representation to a shorter
one, where the value is possibly out of range of the shorter value. (1) If this
is a straight type conversion, the operation is implementation defined (in C and
C++). (2) If, however, it this is the result of performing an operation at a
longer precision and then converting the result back to the orginal precision,
it is undefined. For instance on 64bit hardware we might implement 32-bit
integer addition at 64 bits, followed by a truncation back to 32 bits.
Because we cannot later distinguish b2 from b1, we fail to optimize loops as
best we could. In addition we have explicit extension operations that are nops
in a well formed program.
This is undoubtably a special case of annotating the regular mathematical
operations as wrap,undefined,dont-care on overflow.
I suspect this needs addressing at both the tree-level and the rtl-level
--
Summary: [meta-bug] We need to distinguish value extension and
value truncation
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization, meta-bug
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nathan at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18446
