[PATCH RFC 3/3] Hookize PROMOTE_FUNCTION_MODE with provision for HFmode

Paolo Bonzini bonzini@gnu.org
Wed Apr 22 07:46:00 GMT 2009


Eric Botcazou wrote:
>> What if TARGET_ARCH64 and not TARGET_PTR64?  This is the case I was
>> thinking about; FUNCTION_VALUE will extend pointers to 64-bit,
>> PROMOTE_FUNCTION_MODE doesn't (not even my posted version).  It's
>> probably harmless though, maybe a bit inefficient.
> 
> Pmode == word_mode

Got it now, POINTER_SIZE != GET_MODE_BITSIZE (Pmode).

I'd commit this to make it easier to grasp, do you agree?

Index: gcc/config/sparc/sparc.h
===================================================================
--- gcc/config/sparc/sparc.h    (revision 146547)
+++ gcc/config/sparc/sparc.h    (working copy)
@@ -625,8 +625,10 @@ extern struct sparc_cpu_select sparc_sel
 /* The widest floating-point format really supported by the hardware.  */
 #define WIDEST_HARDWARE_FP_SIZE 64

-/* Width in bits of a pointer.
-   See also the macro `Pmode' defined below.  */
+/* Width in bits of a pointer.  Note that the size of `Pmode' (defined
+   below) is not POINTER_SIZE; when pointers are 32-bit but
+   TARGET_ARCH64 is set, Pmode is a 64-bit mode to which pointers are
+   extended before being accessed.  */
 #define POINTER_SIZE (TARGET_PTR64 ? 64 : 32)

 /* If we have to extend pointers (only when TARGET_ARCH64 and not

> so in both cases we get Pmode, don't we?  Or do you want to 
> add a POINTER_TYPE_P case to function_value for consistency?

Maybe, but it's a different patch.

Paolo



More information about the Gcc-patches mailing list