PATCH: First part of 64-bit Darwin support

[Stan Shebs]

Geoffrey Keating wrote:

>
>>!       if (!TARGET_64BIT) builtin_define ("__ppc__");   \
>>!       if (TARGET_64BIT) builtin_define ("__ppc64__");  \
>>!       if (TARGET_64BIT) builtin_define ("__LP64__");   \
>>    
>>
>
>LP64 is defined by c-ppbuiltin.c, don't define it again.
>  
>
Cool!

>>+   { "64",     MASK_64BIT | MASK_POWERPC64, \
>>+         N_("Generate 64-bit code") }, \
>>+   { "32",     - (MASK_64BIT | MASK_POWERPC64), \
>>+         N_("Generate 32-bit code") }, \
>>    
>>
>
>Don't toggle MASK_POWERPC64 in this code.  Instead, change
>PROCESSOR_DEFAULT64, and add code to SUBTARGET_OVERRIDE_OPTIONS
>to warn people about bogus -mcpu settings, like aix43.h.
>  
>
That makes sense.

>  
>
>>+ (define_insn "adddi3_high"
>>+   [(set (match_operand:DI 0 "gpc_reg_operand" "=b")
>>+         (plus:DI (match_operand:DI 1 "gpc_reg_operand" "b")
>>+                  (high:DI (match_operand 2 "" ""))))]
>>+   "TARGET_MACHO"
>>+   "{cau|addis} %0,%1,ha16(%2)"
>>+   [(set_attr "length" "4")])
>>    
>>
>
>This pattern doesn't have TARGET_64BIT.  I think that's OK, but was it
>intentional?  If so, maybe some other patterns shouldn't have
>TARGET_64BIT either.
>
>  
>
TARGET_64BIT is safer; I'm not sure we want this kicking in for
-mpowerpc64 or some such. Optimization folks can enable for 32-bit
if they figure out that it has an advantage.

>>+ (define_split
>>+   [(set (mem:V4SI (plus:DI (match_operand:DI 0 "gpc_reg_operand" "")
>>+ 			 (match_operand:DI 1 "short_cint_operand" "")))
>>+ 	(match_operand:V4SI 2 "register_operand" ""))
>>+    (clobber (match_operand:DI 3 "gpc_reg_operand" ""))]
>>+   ""
>>+   [(set (match_dup 3) (plus:DI (match_dup 0) (match_dup 1)))
>>+    (set (mem:V4SI (match_dup 3))
>>+ 	(match_dup 2))]
>>+   "")
>>    
>>
>
>This and subsequent patterns needs to have some kind of predicate.
>
>  
>
OK.

>>*** config/rs6000/rs6000.h	11 Aug 2004 19:18:14 -0000	1.330
>>--- config/rs6000/rs6000.h	11 Aug 2004 22:17:09 -0000
>>*************** extern const char *rs6000_warn_altivec_l
>>*** 772,778 ****
>>  #define DATA_ALIGNMENT(TYPE, ALIGN)		\
>>    (TREE_CODE (TYPE) == VECTOR_TYPE ? (TARGET_SPE_ABI ? 64 : 128)	\
>>     : TREE_CODE (TYPE) == ARRAY_TYPE		\
>>!    && TYPE_MODE (TREE_TYPE (TYPE)) == QImode	\
>>     && (ALIGN) < BITS_PER_WORD ? BITS_PER_WORD : (ALIGN))
>>  
>>  /* Nonzero if move instructions will actually fail to work
>>--- 772,779 ----
>>  #define DATA_ALIGNMENT(TYPE, ALIGN)		\
>>    (TREE_CODE (TYPE) == VECTOR_TYPE ? (TARGET_SPE_ABI ? 64 : 128)	\
>>     : TREE_CODE (TYPE) == ARRAY_TYPE		\
>>!    && (TYPE_MODE (TREE_TYPE (TYPE)) == QImode	\
>>!        || TYPE_MODE (TREE_TYPE (TYPE)) == HImode)	\
>>     && (ALIGN) < BITS_PER_WORD ? BITS_PER_WORD : (ALIGN))
>>  
>>  /* Nonzero if move instructions will actually fail to work
>>    
>>
>
>... explain?
>
>  
>
OK, not as obvious as I thought. I'll do this as a separate patch; it 
only came up
in one place in BLAST, where an array of shorts was being incorrectly 
aligned
on 2-byte boundary.

Stan