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

[David Edelsohn]

>>>>> Bradley Lucier writes:

> 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.

	You seem to be defining "quality of implementation" and "bug" to
mean whether the compiler does what you want with "implementation defined"
behavior.  The GCC PowerPC backend could bend over backward to handle the
unusual pointer you are computing, as I have mentioned in another thread.

> 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.

	The code fragment is computing an integer value and storing it in
the location of the adjusted pointer.  GCC is calculating the integer
value in a GPR and choosing to use the GPR for the store because the
PowerPC backend currently allows FP values in 64-bit GPRs.

	The people who do not want FPRs used for non--floating-point
computations might appreciate that the example performs no floating point
computation and uses no FPR.

	Also, in my tests, the type of ___r1 affects the alignment of the
displacement.  What is the type in the original code?

David