Bit-field patch, resurrected

[Joseph S. Myers]

On Fri, 16 Apr 2004, Jim Wilson wrote:

> I think it is reasonable to ask that anyone transforming trees respect
> the TYPE_PRECISION.  The question is whether tree-ssa does or not.  And

As far as I know the transformations on trees respect the TYPE_PRECISION 
(in that they are correct for integers of the type indicated by the 
TYPE_PRECISION, and they do not change the result type).  But I don't see 
that that would stop redundant operations on trees getting optimized away.  
An addition unsigned long long:40 + unsigned long long:40 must have result 
type unsigned long long:40, and if it gets expanded to a conversion to 
that type of a 64-bit addition, it would be entirely correct for tree 
transformations to move the conversion back inside the addition, 
converting it to a 40-bit addition.

The example in bf64-1.c which I simplified in
<http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00651.html> is a case where
the source code didn't contain a bit-field operation; a signed 52-bit
bit-field was (converted to unsigned long long and) compared to an
unsigned 64-bit constant, of which enough high-order bits were 1 that it
was correctly transformed by the compiler to a comparison of 52-bit
unsigned integers - but the signed bit-field got sign-extended to 64-bit
DImode and no code was generated to convert the result to unsigned 52-bit.  
The transformation is correct (even if on bit-fields it's not clear it's
an optimization), and the operation on bit-field types wasn't in the
original source code.

That C bit-fields have hitherto not been given their correct types is the
underlying cause of the bugs this patch addresses.  Giving them their
correct types produces correct trees with these unusual types, which the
front end and fold seem to handle fine, while expand_expr doesn't handle
them.  It is arguable that it would be more correct for every such type to
have its own fractional integer mode to represent more accurately the
different types at RTL level, but that seemed worse than making
expand_expr understand bit-field types narrower than their ordinary
integer modes.

-- 
Joseph S. Myers
jsm@polyomino.org.uk