Re: PATCH:[darwin] fix load of a misaligned double word

[Bradley Lucier <lucier at math dot purdue dot edu>]

On Dec 31, 2003, at 12:28 PM, Andrew Haley wrote:

> It's quite clear from the standard that all you may do with a pointer
> is convert it to a sufficiently aligned pointer of a different type
> and then convert it back.  You may not perform arithmetic on that
> pointer in between.

The standard says:

> 5 An integer may be converted to any pointer type. Except as 
> previously specified, the result is implementation-defined, might not 
> be correctly aligned, might not point to an entity of the referenced 
> type, and might be a trap representation. 56)
>
> 6 Any pointer type may be converted to an integer type. Except as 
> previously specified, the result is implementation-defined. If the 
> result cannot be represented in the integer type, the behavior is 
> undefined. The result need not be in the range of values of any 
> integer type.

"as previously specified" includes only (A) converting an object or 
incomplete type pointer to and from (void *); (B) something about 
q-qualified types that I don't understand; (C) constant expression with 
the value 0 is a null pointer constant, and (D) conversion between null 
pointers of different types.

Any and all other conversions between integers and pointers is 
"implementation defined".

The Rationale for this section says:

> An invalid pointer might be created in several ways.  An arbitrary 
> value can be assigned (via a cast) to a pointer variable.  (This could 
> even create a valid pointer, depending on the value.)  A pointer to an 
> object becomes invalid if the memory containing the object is 
> deallocated or moved by realloc.  Pointer arithmetic can produce 
> pointers outside the range of an array.

So it comes down to a quality of implementation question.  You're 
saying that my "implementation defined" code is clearly wrong, and 
everyone else's "implementation defined" conversion between pointers 
and ints is OK; I have yet to be convinced.

I strongly suspect that it's a bug in the PowerPC64 back end, but I 
have yet to be able to prove it.  My guess is that the offset is 
checked on the pseudo of one type, and that pseudo is then stored in a 
physical register of a different type.

It seems that Apple's code deals with this by putting artificially 
restrictive requirements on the offsets for loads and stores to FPRs; 
at least that's what the first patch did.

There have been many statements about the performance benefits of 
storing FP values in GPRs and 64-bit int values in FPRs.  I don't 
remember seeing any numbers.  There have also been people who wanted 
assurances that the FPRs wouldn't be used in any code that didn't use 
floating-point values, but they seem to have lost the arguments.  Here 
is a real problem caused by the fact that the addressing modes for 
64-bit GPRs and FPRs are not the same.  Perhaps it is time to (perhaps 
temporarily) not store int values in FPRs and FP values in GPRs on 
PPC64.

Brad