* PATCH [3/n] X32: Promote pointers to Pmode @ 2011-07-09 21:37 H.J. Lu 2011-07-10 16:37 ` Uros Bizjak 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-09 21:37 UTC (permalink / raw) To: gcc-patches, Uros Bizjak Hi, X32 psABI requires promoting pointers to Pmode when passing/returning in registers. OK for trunk? Thanks. H.J. -- 2011-07-09 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 04cb07d..c852719 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl, return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); } +/* Pointer function arguments and return values are promoted to + Pmode. */ + +static enum machine_mode +ix86_promote_function_mode (const_tree type, enum machine_mode mode, + int *punsignedp, const_tree fntype, + int for_return) +{ + if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type)) + { + *punsignedp = POINTERS_EXTEND_UNSIGNED; + return Pmode; + } + return default_promote_function_mode (type, mode, punsignedp, fntype, + for_return); +} + rtx ix86_libcall_value (enum machine_mode mode) { @@ -34810,6 +35154,9 @@ ix86_autovectorize_vector_sizes (void) #undef TARGET_FUNCTION_VALUE_REGNO_P #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p +#undef TARGET_PROMOTE_FUNCTION_MODE +#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode + #undef TARGET_SECONDARY_RELOAD #define TARGET_SECONDARY_RELOAD ix86_secondary_reload ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-09 21:37 PATCH [3/n] X32: Promote pointers to Pmode H.J. Lu @ 2011-07-10 16:37 ` Uros Bizjak 2011-07-10 19:56 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Uros Bizjak @ 2011-07-10 16:37 UTC (permalink / raw) To: H.J. Lu; +Cc: gcc-patches On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu <hongjiu.lu@intel.com> wrote: > X32 psABI requires promoting pointers to Pmode when passing/returning > in registers. OK for trunk? > > Thanks. > > H.J. > -- > 2011-07-09 H.J. Lu <hongjiu.lu@intel.com> > > * config/i386/i386.c (ix86_promote_function_mode): New. > (TARGET_PROMOTE_FUNCTION_MODE): Likewise. > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 04cb07d..c852719 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl, > return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); > } > > +/* Pointer function arguments and return values are promoted to > + Pmode. */ > + > +static enum machine_mode > +ix86_promote_function_mode (const_tree type, enum machine_mode mode, > + int *punsignedp, const_tree fntype, > + int for_return) > +{ > + if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type)) > + { > + *punsignedp = POINTERS_EXTEND_UNSIGNED; > + return Pmode; > + } > + return default_promote_function_mode (type, mode, punsignedp, fntype, > + for_return); > +} Please rewrite the condition to: if (for_return == 1) /* Do not promote function return values. */ ; else if (type != NULL_TREE && ...) Also, please add some comments. Your comment also says that pointer return arguments are promoted to Pmode. The documentation says that: FOR_RETURN allows to distinguish the promotion of arguments and return values. If it is `1', a return value is being promoted and `TARGET_FUNCTION_VALUE' must perform the same promotions done here. If it is `2', the returned mode should be that of the register in which an incoming parameter is copied, or the outgoing result is computed; then the hook should return the same mode as `promote_mode', though the signedness may be different. You bypass promotions when FOR_RETURN is 1. Uros. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-10 16:37 ` Uros Bizjak @ 2011-07-10 19:56 ` H.J. Lu 2011-07-10 23:51 ` Richard Henderson 2011-07-13 13:42 ` H.J. Lu 0 siblings, 2 replies; 22+ messages in thread From: H.J. Lu @ 2011-07-10 19:56 UTC (permalink / raw) To: Uros Bizjak; +Cc: gcc-patches On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu <hongjiu.lu@intel.com> wrote: > >> X32 psABI requires promoting pointers to Pmode when passing/returning >> in registers. OK for trunk? >> >> Thanks. >> >> H.J. >> -- >> 2011-07-09 H.J. Lu <hongjiu.lu@intel.com> >> >> * config/i386/i386.c (ix86_promote_function_mode): New. >> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c >> index 04cb07d..c852719 100644 >> --- a/gcc/config/i386/i386.c >> +++ b/gcc/config/i386/i386.c >> @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl, >> return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); >> } >> >> +/* Pointer function arguments and return values are promoted to >> + Pmode. */ >> + >> +static enum machine_mode >> +ix86_promote_function_mode (const_tree type, enum machine_mode mode, >> + int *punsignedp, const_tree fntype, >> + int for_return) >> +{ >> + if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type)) >> + { >> + *punsignedp = POINTERS_EXTEND_UNSIGNED; >> + return Pmode; >> + } >> + return default_promote_function_mode (type, mode, punsignedp, fntype, >> + for_return); >> +} > > Please rewrite the condition to: > > if (for_return == 1) > /* Do not promote function return values. */ > ; > else if (type != NULL_TREE && ...) > > Also, please add some comments. > > Your comment also says that pointer return arguments are promoted to > Pmode. The documentation says that: > > FOR_RETURN allows to distinguish the promotion of arguments and > return values. If it is `1', a return value is being promoted and > `TARGET_FUNCTION_VALUE' must perform the same promotions done here. > If it is `2', the returned mode should be that of the register in > which an incoming parameter is copied, or the outgoing result is > computed; then the hook should return the same mode as > `promote_mode', though the signedness may be different. > > You bypass promotions when FOR_RETURN is 1. > > Uros. > Here is the updated patch. OK for trunk? Thanks. -- H.J. -- 2011-07-10 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 04cb07d..1b02312 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -2973,6 +2973,9 @@ ix86_option_override_internal (bool main_args_p) SUBSUBTARGET_OVERRIDE_OPTIONS; #endif + if (TARGET_X32) + ix86_isa_flags |= OPTION_MASK_ISA_64BIT; + /* -fPIC is the default for x86_64. */ if (TARGET_MACHO && TARGET_64BIT) @@ -7052,6 +7061,27 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl, return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); } +/* Pointer function arguments and return values are promoted to Pmode. + If FOR_RETURN is 1, this function must behave in the same way with + regard to function returns as TARGET_FUNCTION_VALUE. */ + +static enum machine_mode +ix86_promote_function_mode (const_tree type, enum machine_mode mode, + int *punsignedp, const_tree fntype, + int for_return) +{ + if (for_return == 1) + /* Do not promote function return values. */ + ; + else if (type != NULL_TREE && POINTER_TYPE_P (type)) + { + *punsignedp = POINTERS_EXTEND_UNSIGNED; + return Pmode; + } + return default_promote_function_mode (type, mode, punsignedp, fntype, + for_return); +} + rtx ix86_libcall_value (enum machine_mode mode) { @@ -34810,6 +35157,9 @@ ix86_autovectorize_vector_sizes (void) #undef TARGET_FUNCTION_VALUE_REGNO_P #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p +#undef TARGET_PROMOTE_FUNCTION_MODE +#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode + #undef TARGET_SECONDARY_RELOAD #define TARGET_SECONDARY_RELOAD ix86_secondary_reload ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-10 19:56 ` H.J. Lu @ 2011-07-10 23:51 ` Richard Henderson 2011-07-11 0:04 ` H.J. Lu 2011-07-13 13:42 ` H.J. Lu 1 sibling, 1 reply; 22+ messages in thread From: Richard Henderson @ 2011-07-10 23:51 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/10/2011 12:43 PM, H.J. Lu wrote: > +/* Pointer function arguments and return values are promoted to Pmode. > + If FOR_RETURN is 1, this function must behave in the same way with > + regard to function returns as TARGET_FUNCTION_VALUE. */ > + > +static enum machine_mode > +ix86_promote_function_mode (const_tree type, enum machine_mode mode, > + int *punsignedp, const_tree fntype, > + int for_return) > +{ > + if (for_return == 1) > + /* Do not promote function return values. */ > + ; > + else if (type != NULL_TREE && POINTER_TYPE_P (type)) These two comments still conflict. And why wouldn't you want to promote return values? r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-10 23:51 ` Richard Henderson @ 2011-07-11 0:04 ` H.J. Lu 2011-07-11 1:16 ` Richard Henderson 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-11 0:04 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Sun, Jul 10, 2011 at 2:44 PM, Richard Henderson <rth@redhat.com> wrote: > On 07/10/2011 12:43 PM, H.J. Lu wrote: >> +/* Pointer function arguments and return values are promoted to Pmode. >> + If FOR_RETURN is 1, this function must behave in the same way with >> + regard to function returns as TARGET_FUNCTION_VALUE. */ >> + >> +static enum machine_mode >> +ix86_promote_function_mode (const_tree type, enum machine_mode mode, >> + int *punsignedp, const_tree fntype, >> + int for_return) >> +{ >> + if (for_return == 1) >> + /* Do not promote function return values. */ >> + ; >> + else if (type != NULL_TREE && POINTER_TYPE_P (type)) > > These two comments still conflict. And why wouldn't you want to > promote return values? We only want to promote function parameters passed/returned in register. But I can't tell if a value will be passed in register or memory inside of TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't promote. Even if we don't promote it explicitly, hardware still zero-extends it for us. So it isn't a real issue. -- H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-11 0:04 ` H.J. Lu @ 2011-07-11 1:16 ` Richard Henderson 2011-07-11 1:47 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Richard Henderson @ 2011-07-11 1:16 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/10/2011 03:01 PM, H.J. Lu wrote: > We only want to promote function parameters passed/returned in register. > But I can't tell if a value will be passed in register or memory inside of > TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't > promote. Even if we don't promote it explicitly, hardware still zero-extends > it for us. So it isn't a real issue. The hardware *usually* zero-extends. It all depends on where the data is coming from. Without certainty, i.e. actually representing it properly, you're designing a broken ABI. What you wrote above re T_F_V not being able to tell register or memory doesn't make sense. Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE? And why exactly wouldn't you be able to tell there? Can you not find out via a call to ix86_return_in_memory? r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-11 1:16 ` Richard Henderson @ 2011-07-11 1:47 ` H.J. Lu 2011-07-13 14:07 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-11 1:47 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <rth@redhat.com> wrote: > On 07/10/2011 03:01 PM, H.J. Lu wrote: >> We only want to promote function parameters passed/returned in register. >> But I can't tell if a value will be passed in register or memory inside of >> TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't >> promote. Even if we don't promote it explicitly, hardware still zero-extends >> it for us. So it isn't a real issue. > > The hardware *usually* zero-extends. It all depends on where the data is > coming from. Without certainty, i.e. actually representing it properly, > you're designing a broken ABI. > > What you wrote above re T_F_V not being able to tell register or > memory doesn't make sense. Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE? > And why exactly wouldn't you be able to tell there? Can you not find out > via a call to ix86_return_in_memory? > TARGET_PROMOTE_FUNCTION_MODE is for passing/returning value in a register and the documentation says that: FOR_RETURN allows to distinguish the promotion of arguments and return values. If it is `1', a return value is being promoted and `TARGET_FUNCTION_VALUE' must perform the same promotions done here. If it is `2', the returned mode should be that of the register in which an incoming parameter is copied, or the outgoing result is computed; then the hook should return the same mode as `promote_mode', though the signedness may be different. But for TARGET_FUNCTION_VALUE, there is no difference for register and memory. That is why I don't promote when FOR_RETURN is 1. mmix/mmix.c and rx/rx.c have similar treatment. -- H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-11 1:47 ` H.J. Lu @ 2011-07-13 14:07 ` H.J. Lu 2011-07-13 15:36 ` Richard Henderson 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-13 14:07 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches Hi Richard, Is my patch OK? Thanks. H.J. ---- On Sun, Jul 10, 2011 at 6:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <rth@redhat.com> wrote: >> On 07/10/2011 03:01 PM, H.J. Lu wrote: >>> We only want to promote function parameters passed/returned in register. >>> But I can't tell if a value will be passed in register or memory inside of >>> TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't >>> promote. Even if we don't promote it explicitly, hardware still zero-extends >>> it for us. So it isn't a real issue. >> >> The hardware *usually* zero-extends. It all depends on where the data is >> coming from. Without certainty, i.e. actually representing it properly, >> you're designing a broken ABI. >> >> What you wrote above re T_F_V not being able to tell register or >> memory doesn't make sense. Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE? >> And why exactly wouldn't you be able to tell there? Can you not find out >> via a call to ix86_return_in_memory? >> > > TARGET_PROMOTE_FUNCTION_MODE is for passing/returning > value in a register and the documentation says that: > > FOR_RETURN allows to distinguish the promotion of arguments and > return values. If it is `1', a return value is being promoted and > `TARGET_FUNCTION_VALUE' must perform the same promotions done here. > If it is `2', the returned mode should be that of the register in > which an incoming parameter is copied, or the outgoing result is > computed; then the hook should return the same mode as > `promote_mode', though the signedness may be different. > > > But for TARGET_FUNCTION_VALUE, there is no difference for > register and memory. That is why I don't promote when > FOR_RETURN is 1. mmix/mmix.c and rx/rx.c have similar > treatment. > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-13 14:07 ` H.J. Lu @ 2011-07-13 15:36 ` Richard Henderson 2011-07-13 15:38 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Richard Henderson @ 2011-07-13 15:36 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/13/2011 07:02 AM, H.J. Lu wrote: > Hi Richard, > > Is my patch OK? No, I don't think it is. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-13 15:36 ` Richard Henderson @ 2011-07-13 15:38 ` H.J. Lu 2011-07-13 16:13 ` Richard Henderson 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-13 15:38 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/13/2011 07:02 AM, H.J. Lu wrote: >> Hi Richard, >> >> Is my patch OK? > > No, I don't think it is. > What is your suggestion? -- H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-13 15:38 ` H.J. Lu @ 2011-07-13 16:13 ` Richard Henderson 2011-07-14 7:36 ` H.J. Lu 2011-07-21 22:30 ` H.J. Lu 0 siblings, 2 replies; 22+ messages in thread From: Richard Henderson @ 2011-07-13 16:13 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/13/2011 08:35 AM, H.J. Lu wrote: > On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote: >> On 07/13/2011 07:02 AM, H.J. Lu wrote: >>> Hi Richard, >>> >>> Is my patch OK? >> >> No, I don't think it is. >> > > What is your suggestion? Promote the return value. If that means it doesn't match function_value, then I suggest that function_value is wrong. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-13 16:13 ` Richard Henderson @ 2011-07-14 7:36 ` H.J. Lu 2011-07-21 22:30 ` H.J. Lu 1 sibling, 0 replies; 22+ messages in thread From: H.J. Lu @ 2011-07-14 7:36 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/13/2011 08:35 AM, H.J. Lu wrote: >> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote: >>> On 07/13/2011 07:02 AM, H.J. Lu wrote: >>>> Hi Richard, >>>> >>>> Is my patch OK? >>> >>> No, I don't think it is. >>> >> >> What is your suggestion? > > Promote the return value. If that means it doesn't match function_value, > then I suggest that function_value is wrong. > > static enum machine_mode ix86_promote_function_mode (const_tree type, enum machine_mode mode, int *punsignedp, const_tree fntype, int for_return) { if (type != NULL_TREE && POINTER_TYPE_P (type)) { *punsignedp = POINTERS_EXTEND_UNSIGNED; return Pmode; } return default_promote_function_mode (type, mode, punsignedp, fntype, for_return); } doesn't work. I got In file included from /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_div_macros.h:27:0, from /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid128_div.c:25: /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_internal.h: In function \u2018handle_UF_128.constprop.7\u2019: /export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_internal.h:1626:1: internal compiler error: in emit_move_insn, at expr.c:3349 Please submit a full bug report, with preprocessed source if appropriate. TARGET_FUNCTION_VALUE shouldn't promote pointers to Pmode since it will also promote pointers passed in memory, which aren't needed nor desired. Since x86-64 processors ALWAYS zero-extend 32bit to 64bit when writing 32bit registers, it is OK not to promote pointers in TARGET_FUNCTION_VALUE. We only need to promote pointers to static enum machine_mode ix86_promote_function_mode (const_tree type, enum machine_mode mode, int *punsignedp, const_tree fntype, int for_return) { if (for_return == 1) /* Do not promote function return values. */ ; else if (type != NULL_TREE && POINTER_TYPE_P (type)) { *punsignedp = POINTERS_EXTEND_UNSIGNED; return Pmode; } return default_promote_function_mode (type, mode, punsignedp, fntype, for_return); } Richard, can you tell me what the real problem with my approach is? Thanks. -- H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-13 16:13 ` Richard Henderson 2011-07-14 7:36 ` H.J. Lu @ 2011-07-21 22:30 ` H.J. Lu 2011-07-21 22:46 ` Richard Henderson 1 sibling, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-21 22:30 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches [-- Attachment #1: Type: text/plain, Size: 807 bytes --] On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson <rth@redhat.com> wrote: > On 07/13/2011 08:35 AM, H.J. Lu wrote: >> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote: >>> On 07/13/2011 07:02 AM, H.J. Lu wrote: >>>> Hi Richard, >>>> >>>> Is my patch OK? >>> >>> No, I don't think it is. >>> >> >> What is your suggestion? > > Promote the return value. If that means it doesn't match function_value, > then I suggest that function_value is wrong. > > > r~ > This is the patch I am testing. I will check it in if it works. Thanks. -- H.J. --- 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (function_value_64): Always return pointers in Pmode. (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. [-- Attachment #2: gcc-x32-abi-3.patch --] [-- Type: text/x-diff, Size: 1798 bytes --] 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (function_value_64): Always return pointers in Pmode. (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index da6c888..32af303 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -7078,6 +7078,11 @@ function_value_64 (enum machine_mode orig_mode, enum machine_mode mode, return gen_rtx_REG (mode, AX_REG); } } + else if (POINTER_TYPE_P (valtype)) + { + /* Pointers are always returned in Pmode. */ + mode = Pmode; + } ret = construct_container (mode, orig_mode, valtype, 1, X86_64_REGPARM_MAX, X86_64_SSE_REGPARM_MAX, @@ -7147,6 +7152,22 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl, return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); } +/* Pointer function arguments and return values are promoted to Pmode. */ + +static enum machine_mode +ix86_promote_function_mode (const_tree type, enum machine_mode mode, + int *punsignedp, const_tree fntype, + int for_return) +{ + if (type != NULL_TREE && POINTER_TYPE_P (type)) + { + *punsignedp = POINTERS_EXTEND_UNSIGNED; + return Pmode; + } + return default_promote_function_mode (type, mode, punsignedp, fntype, + for_return); +} + rtx ix86_libcall_value (enum machine_mode mode) { @@ -34970,6 +35055,9 @@ ix86_autovectorize_vector_sizes (void) #undef TARGET_FUNCTION_VALUE_REGNO_P #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p +#undef TARGET_PROMOTE_FUNCTION_MODE +#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode + #undef TARGET_SECONDARY_RELOAD #define TARGET_SECONDARY_RELOAD ix86_secondary_reload ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-21 22:30 ` H.J. Lu @ 2011-07-21 22:46 ` Richard Henderson 2011-07-22 0:10 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Richard Henderson @ 2011-07-21 22:46 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/21/2011 03:02 PM, H.J. Lu wrote: > * config/i386/i386.c (function_value_64): Always return pointers > in Pmode. > (ix86_promote_function_mode): New. > (TARGET_PROMOTE_FUNCTION_MODE): Likewise. Much better, thanks. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-21 22:46 ` Richard Henderson @ 2011-07-22 0:10 ` H.J. Lu 2011-07-22 3:23 ` Richard Henderson 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-22 0:10 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 03:02 PM, H.J. Lu wrote: >> * config/i386/i386.c (function_value_64): Always return pointers >> in Pmode. >> (ix86_promote_function_mode): New. >> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. > > Much better, thanks. > > > r~ > Also need this patch. Otherwise, I got FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error) FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors) FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error) FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors) OK for trunk? Thanks. -- H.J. -- 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (function_value_ms_64): Take a new argument. Always return pointers in Pmode. (ix86_function_value_1): Updated. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index b603f4e..9bc2eef 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -7097,11 +7097,17 @@ function_value_64 (enum machine_mode orig_mode, enum machine_mode mode, } static rtx -function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode) +function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode, + const_tree valtype) { unsigned int regno = AX_REG; - if (TARGET_SSE) + if (valtype && POINTER_TYPE_P (valtype)) + { + /* Pointers are always returned in Pmode. */ + orig_mode = Pmode; + } + else if (TARGET_SSE) { switch (GET_MODE_SIZE (mode)) { @@ -7134,7 +7140,7 @@ ix86_function_value_1 (const_tree valtype, const_tree fntype_or_decl, fntype = fn ? TREE_TYPE (fn) : fntype_or_decl; if (TARGET_64BIT && ix86_function_type_abi (fntype) == MS_ABI) - return function_value_ms_64 (orig_mode, mode); + return function_value_ms_64 (orig_mode, mode, valtype); else if (TARGET_64BIT) return function_value_64 (orig_mode, mode, valtype); else ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-22 0:10 ` H.J. Lu @ 2011-07-22 3:23 ` Richard Henderson 2011-07-22 4:22 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: Richard Henderson @ 2011-07-22 3:23 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/21/2011 04:28 PM, H.J. Lu wrote: > On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote: >> On 07/21/2011 03:02 PM, H.J. Lu wrote: >>> * config/i386/i386.c (function_value_64): Always return pointers >>> in Pmode. >>> (ix86_promote_function_mode): New. >>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >> >> Much better, thanks. >> >> >> r~ >> > > Also need this patch. Otherwise, I got > > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error) > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors) > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error) > FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors) > > OK for trunk? Hmm. Should we even be running ms_64 callabi tests across pointer sizes though? r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-22 3:23 ` Richard Henderson @ 2011-07-22 4:22 ` H.J. Lu 2011-07-22 8:08 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-22 4:22 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson <rth@redhat.com> wrote: > On 07/21/2011 04:28 PM, H.J. Lu wrote: >> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote: >>> On 07/21/2011 03:02 PM, H.J. Lu wrote: >>>> * config/i386/i386.c (function_value_64): Always return pointers >>>> in Pmode. >>>> (ix86_promote_function_mode): New. >>>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >>> >>> Much better, thanks. >>> >>> >>> r~ >>> >> >> Also need this patch. Otherwise, I got >> >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error) >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors) >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error) >> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors) >> >> OK for trunk? > > Hmm. Should we even be running ms_64 callabi tests across pointer sizes though? > Good question. I can disable the test. But compiler will still ICE on this input. -- H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-22 4:22 ` H.J. Lu @ 2011-07-22 8:08 ` H.J. Lu 2011-07-22 13:31 ` H.J. Lu 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-22 8:08 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches On Thu, Jul 21, 2011 at 5:36 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson <rth@redhat.com> wrote: >> On 07/21/2011 04:28 PM, H.J. Lu wrote: >>> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote: >>>> On 07/21/2011 03:02 PM, H.J. Lu wrote: >>>>> * config/i386/i386.c (function_value_64): Always return pointers >>>>> in Pmode. >>>>> (ix86_promote_function_mode): New. >>>>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >>>> >>>> Much better, thanks. >>>> >>>> >>>> r~ >>>> >>> >>> Also need this patch. Otherwise, I got >>> >>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error) >>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors) >>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error) >>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors) >>> >>> OK for trunk? >> >> Hmm. Should we even be running ms_64 callabi tests across pointer sizes though? >> > > Good question. I can disable the test. But compiler will still ICE on this > input. > > How about this patch? OK for trunk? Thanks. -- H.J. --- gcc/ 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (ix86_option_override_internal): Disallow MS ABI in x32 mode. (ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi only for TARGET_LP64. (ix86_handle_abi_attribute): Check TARGET_LP64 instead of TARGET_64BIT. gcc/testsuite/ 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32 instead of ia32. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 9e3532e..6e030d9 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -3133,6 +3133,9 @@ ix86_option_override_internal (bool main_args_p) if (!global_options_set.x_ix86_abi) ix86_abi = DEFAULT_ABI; + if (ix86_abi == MS_ABI && TARGET_X32) + error ("MS ABI not supported in x32 mode"); + if (global_options_set.x_ix86_cmodel) { switch (ix86_cmodel) @@ -25520,7 +25523,7 @@ ix86_init_builtins (void) ix86_init_mmx_sse_builtins (); - if (TARGET_64BIT) + if (TARGET_LP64) ix86_init_builtins_va_builtins_abi (); #ifdef SUBTARGET_INIT_BUILTINS @@ -29340,7 +29343,7 @@ ix86_handle_abi_attribute (tree *node, tree name, *no_add_attrs = true; return NULL_TREE; } - if (!TARGET_64BIT) + if (!TARGET_LP64) { warning (OPT_Wattributes, "%qE attribute only available for 64-bit", name); diff --git a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp index b0cba17..e76d0c1 100644 --- a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp +++ b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp @@ -20,7 +20,7 @@ load_lib gcc-dg.exp if { (![istarget x86_64-*-*] && ![istarget i?86-*-*]) - || [is-effective-target ia32] } then { + || [is-effective-target ilp32] } then { return } ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-22 8:08 ` H.J. Lu @ 2011-07-22 13:31 ` H.J. Lu 2011-07-22 16:34 ` Richard Henderson 0 siblings, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-22 13:31 UTC (permalink / raw) To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches [-- Attachment #1: Type: text/plain, Size: 2203 bytes --] On Thu, Jul 21, 2011 at 10:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Thu, Jul 21, 2011 at 5:36 PM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson <rth@redhat.com> wrote: >>> On 07/21/2011 04:28 PM, H.J. Lu wrote: >>>> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote: >>>>> On 07/21/2011 03:02 PM, H.J. Lu wrote: >>>>>> * config/i386/i386.c (function_value_64): Always return pointers >>>>>> in Pmode. >>>>>> (ix86_promote_function_mode): New. >>>>>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >>>>> >>>>> Much better, thanks. >>>>> >>>>> >>>>> r~ >>>>> >>>> >>>> Also need this patch. Otherwise, I got >>>> >>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error) >>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors) >>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error) >>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors) >>>> >>>> OK for trunk? >>> >>> Hmm. Should we even be running ms_64 callabi tests across pointer sizes though? >>> >> >> Good question. I can disable the test. But compiler will still ICE on this >> input. >> >> > > How about this patch? OK for trunk? > Need to skip all ms_abi tests for x32. OK for trunk? Thanks. H.J. ---- gcc/ 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (ix86_option_override_internal): Disallow MS ABI in x32 mode. (ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi only for TARGET_LP64. (ix86_handle_abi_attribute): Check TARGET_LP64 instead of TARGET_64BIT. gcc/testsuite/ 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c: Only run on lp64 targets. * gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c: Likewise. * gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c: Likewise. * gcc/testsuite/gcc.target/i386/pr43662.c: Likewise. * gcc/testsuite/gcc.target/i386/pr43869.c: Likewise. * gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32 instead of ia32. [-- Attachment #2: gcc-x32-abi-ms-2.patch --] [-- Type: text/plain, Size: 4504 bytes --] gcc/ 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * config/i386/i386.c (ix86_option_override_internal): Disallow MS ABI in x32 mode. (ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi only for TARGET_LP64. (ix86_handle_abi_attribute): Check TARGET_LP64 instead of TARGET_64BIT. gcc/testsuite/ 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> * gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c: Only run on lp64 targets. * gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c: Likewise. * gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c: Likewise. * gcc/testsuite/gcc.target/i386/pr43662.c: Likewise. * gcc/testsuite/gcc.target/i386/pr43869.c: Likewise. * gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32 instead of ia32. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 9e3532e..6e030d9 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -3133,6 +3133,9 @@ ix86_option_override_internal (bool main_args_p) if (!global_options_set.x_ix86_abi) ix86_abi = DEFAULT_ABI; + if (ix86_abi == MS_ABI && TARGET_X32) + error ("MS ABI not supported in x32 mode"); + if (global_options_set.x_ix86_cmodel) { switch (ix86_cmodel) @@ -25520,7 +25523,7 @@ ix86_init_builtins (void) ix86_init_mmx_sse_builtins (); - if (TARGET_64BIT) + if (TARGET_LP64) ix86_init_builtins_va_builtins_abi (); #ifdef SUBTARGET_INIT_BUILTINS @@ -29340,7 +29343,7 @@ ix86_handle_abi_attribute (tree *node, tree name, *no_add_attrs = true; return NULL_TREE; } - if (!TARGET_64BIT) + if (!TARGET_LP64) { warning (OPT_Wattributes, "%qE attribute only available for 64-bit", name); diff --git a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp index b0cba17..e76d0c1 100644 --- a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp +++ b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp @@ -20,7 +20,7 @@ load_lib gcc-dg.exp if { (![istarget x86_64-*-*] && ![istarget i?86-*-*]) - || [is-effective-target ia32] } then { + || [is-effective-target ilp32] } then { return } diff --git a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c index 095640a..bc6e0d2 100644 --- a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c +++ b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c @@ -1,4 +1,4 @@ -/* { dg-do compile { target { ! { ia32 } } } } */ +/* { dg-do compile { target lp64 } } */ /* { dg-options "-O2 -mavx -mabi=ms -mtune=generic -dp" } */ typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__)); diff --git a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c index ef293b3..5d3aa48 100644 --- a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c +++ b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c @@ -1,4 +1,4 @@ -/* { dg-do compile { target { ! { ia32 } } } } */ +/* { dg-do compile { target lp64 } } */ /* { dg-options "-O2 -mavx -mabi=ms -mtune=generic -dp" } */ typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__)); diff --git a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c index 046b7ef..0630752 100644 --- a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c +++ b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c @@ -1,4 +1,4 @@ -/* { dg-do compile { target { ! { ia32 } } } } */ +/* { dg-do compile { target lp64 } } */ /* { dg-options "-O0 -mavx -mabi=ms -mtune=generic -dp" } */ typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__)); diff --git a/gcc/testsuite/gcc.target/i386/pr43662.c b/gcc/testsuite/gcc.target/i386/pr43662.c index 5e75dc5..2896a1a 100644 --- a/gcc/testsuite/gcc.target/i386/pr43662.c +++ b/gcc/testsuite/gcc.target/i386/pr43662.c @@ -1,4 +1,4 @@ -/* { dg-do compile { target { ! { ia32 } } } } */ +/* { dg-do compile { target lp64 } } */ /* { dg-options "-O2" } */ void __attribute__ ((ms_abi)) foo (void) diff --git a/gcc/testsuite/gcc.target/i386/pr43869.c b/gcc/testsuite/gcc.target/i386/pr43869.c index 5513b19..4157db1 100644 --- a/gcc/testsuite/gcc.target/i386/pr43869.c +++ b/gcc/testsuite/gcc.target/i386/pr43869.c @@ -1,4 +1,4 @@ -/* { dg-do compile { target { ! { ia32 } } } } */ +/* { dg-do compile { target lp64 } } */ int __attribute__((__noinline__)) bugged(float f1, float f2, float f3, float f4, ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-22 13:31 ` H.J. Lu @ 2011-07-22 16:34 ` Richard Henderson 0 siblings, 0 replies; 22+ messages in thread From: Richard Henderson @ 2011-07-22 16:34 UTC (permalink / raw) To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches On 07/22/2011 06:07 AM, H.J. Lu wrote: > 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> > > * config/i386/i386.c (ix86_option_override_internal): Disallow > MS ABI in x32 mode. > (ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi > only for TARGET_LP64. > (ix86_handle_abi_attribute): Check TARGET_LP64 instead of > TARGET_64BIT. > > gcc/testsuite/ > > 2011-07-21 H.J. Lu <hongjiu.lu@intel.com> > > * gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c: Only run > on lp64 targets. > * gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c: Likewise. > * gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c: Likewise. > * gcc/testsuite/gcc.target/i386/pr43662.c: Likewise. > * gcc/testsuite/gcc.target/i386/pr43869.c: Likewise. > > * gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32 > instead of ia32. Ok. r~ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-10 19:56 ` H.J. Lu 2011-07-10 23:51 ` Richard Henderson @ 2011-07-13 13:42 ` H.J. Lu 2011-07-13 13:48 ` Uros Bizjak 1 sibling, 1 reply; 22+ messages in thread From: H.J. Lu @ 2011-07-13 13:42 UTC (permalink / raw) To: Uros Bizjak; +Cc: gcc-patches PING. On Sun, Jul 10, 2011 at 12:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak <ubizjak@gmail.com> wrote: >> On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu <hongjiu.lu@intel.com> wrote: >> >>> X32 psABI requires promoting pointers to Pmode when passing/returning >>> in registers. OK for trunk? >>> >>> Thanks. >>> >>> H.J. >>> -- >>> 2011-07-09 H.J. Lu <hongjiu.lu@intel.com> >>> >>> * config/i386/i386.c (ix86_promote_function_mode): New. >>> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. >>> >>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c >>> index 04cb07d..c852719 100644 >>> --- a/gcc/config/i386/i386.c >>> +++ b/gcc/config/i386/i386.c >>> @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl, >>> return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); >>> } >>> >>> +/* Pointer function arguments and return values are promoted to >>> + Pmode. */ >>> + >>> +static enum machine_mode >>> +ix86_promote_function_mode (const_tree type, enum machine_mode mode, >>> + int *punsignedp, const_tree fntype, >>> + int for_return) >>> +{ >>> + if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type)) >>> + { >>> + *punsignedp = POINTERS_EXTEND_UNSIGNED; >>> + return Pmode; >>> + } >>> + return default_promote_function_mode (type, mode, punsignedp, fntype, >>> + for_return); >>> +} >> >> Please rewrite the condition to: >> >> if (for_return == 1) >> /* Do not promote function return values. */ >> ; >> else if (type != NULL_TREE && ...) >> >> Also, please add some comments. >> >> Your comment also says that pointer return arguments are promoted to >> Pmode. The documentation says that: >> >> FOR_RETURN allows to distinguish the promotion of arguments and >> return values. If it is `1', a return value is being promoted and >> `TARGET_FUNCTION_VALUE' must perform the same promotions done here. >> If it is `2', the returned mode should be that of the register in >> which an incoming parameter is copied, or the outgoing result is >> computed; then the hook should return the same mode as >> `promote_mode', though the signedness may be different. >> >> You bypass promotions when FOR_RETURN is 1. >> >> Uros. >> > > Here is the updated patch. OK for trunk? > > Thanks. > > -- > H.J. > -- > 2011-07-10 H.J. Lu <hongjiu.lu@intel.com> > > * config/i386/i386.c (ix86_promote_function_mode): New. > (TARGET_PROMOTE_FUNCTION_MODE): Likewise. > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 04cb07d..1b02312 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/config/i386/i386.c > @@ -7052,6 +7061,27 @@ ix86_function_value (const_tree valtype, > const_tree fntype_or_decl, > return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode); > } > > +/* Pointer function arguments and return values are promoted to Pmode. > + If FOR_RETURN is 1, this function must behave in the same way with > + regard to function returns as TARGET_FUNCTION_VALUE. */ > + > +static enum machine_mode > +ix86_promote_function_mode (const_tree type, enum machine_mode mode, > + int *punsignedp, const_tree fntype, > + int for_return) > +{ > + if (for_return == 1) > + /* Do not promote function return values. */ > + ; > + else if (type != NULL_TREE && POINTER_TYPE_P (type)) > + { > + *punsignedp = POINTERS_EXTEND_UNSIGNED; > + return Pmode; > + } > + return default_promote_function_mode (type, mode, punsignedp, fntype, > + for_return); > +} > + > rtx > ix86_libcall_value (enum machine_mode mode) > { > @@ -34810,6 +35157,9 @@ ix86_autovectorize_vector_sizes (void) > #undef TARGET_FUNCTION_VALUE_REGNO_P > #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p > > +#undef TARGET_PROMOTE_FUNCTION_MODE > +#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode > + > #undef TARGET_SECONDARY_RELOAD > #define TARGET_SECONDARY_RELOAD ix86_secondary_reload > -- H.J. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: PATCH [3/n] X32: Promote pointers to Pmode 2011-07-13 13:42 ` H.J. Lu @ 2011-07-13 13:48 ` Uros Bizjak 0 siblings, 0 replies; 22+ messages in thread From: Uros Bizjak @ 2011-07-13 13:48 UTC (permalink / raw) To: H.J. Lu; +Cc: gcc-patches, Richard Henderson On Wed, Jul 13, 2011 at 3:17 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > PING. >> 2011-07-10 H.J. Lu <hongjiu.lu@intel.com> >> >> * config/i386/i386.c (ix86_promote_function_mode): New. >> (TARGET_PROMOTE_FUNCTION_MODE): Likewise. You have discussed this with rth, the final approval should be from him. Uros. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-07-22 15:54 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-09 21:37 PATCH [3/n] X32: Promote pointers to Pmode H.J. Lu 2011-07-10 16:37 ` Uros Bizjak 2011-07-10 19:56 ` H.J. Lu 2011-07-10 23:51 ` Richard Henderson 2011-07-11 0:04 ` H.J. Lu 2011-07-11 1:16 ` Richard Henderson 2011-07-11 1:47 ` H.J. Lu 2011-07-13 14:07 ` H.J. Lu 2011-07-13 15:36 ` Richard Henderson 2011-07-13 15:38 ` H.J. Lu 2011-07-13 16:13 ` Richard Henderson 2011-07-14 7:36 ` H.J. Lu 2011-07-21 22:30 ` H.J. Lu 2011-07-21 22:46 ` Richard Henderson 2011-07-22 0:10 ` H.J. Lu 2011-07-22 3:23 ` Richard Henderson 2011-07-22 4:22 ` H.J. Lu 2011-07-22 8:08 ` H.J. Lu 2011-07-22 13:31 ` H.J. Lu 2011-07-22 16:34 ` Richard Henderson 2011-07-13 13:42 ` H.J. Lu 2011-07-13 13:48 ` Uros Bizjak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).