Re: GCC 4.3.0 Status Report (2007-09-04)
On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote: Other than that, the patch looks pretty good to me. However, I'd like a middle-end maintainer to review the patch. Ian, Diego, Roger, would one of you please take a look? Well... ping? to use the --param mechanism. Our policy is to have *no* magic numbers for these kinds of things. It's easy enough to allow users to use --param to set the values, and that makes it easy for people (often the compiler developers themselves) to experiment with the values to help fine-tune the defaults. I have changed the patch accordingly, it can still be found at: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00972.html Thanks, Martin
Re: GCC 4.3.0 Status Report (2007-09-04)
Mark, Kai Tietz wrote: Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all calling-convention predicates ought to be looking at the type to support calling through function pointers? This macro is used also in builtin's and libcalls subject where the FUNC_DECL is a null reference. Also in most places the FUNC_DECL is allready present. To avoid duplicate code to check and get the FUNC_TYPE by FUNC_DECL, I choose to pass the function declaration. I'm sorry -- that doesn't really answer the question I was trying to ask. To be clear, if we're calling through a function pointer, we still need to be able to do the right thing, and in that case we don't have a FUNCTION_DECL. So, I don't understand how you can have a macro to control the calling convention that accepts a FUNCTION_DECL; I would think it would have to accept a FUNCTION_TYPE. Sorry, I think I missed your question. To make the macro OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no special reason for it. I deceided this to make it accepting a FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend. In some cases there is no fntype nor a valid fndecl and (a NULL value), but there is the FUNCTION_DECL type allready present, therefore I choose the FUNCTION_DECL type instead of the FUNCTION_TYPE. I think, I used it to be according to the REG_PARM_STACK_SPACE macro. If this is a serious problem, of course I can move this to a FUNCTION_TYPE. Are there some special needs to have here FUNCTION_TYPE ? Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: GCC 4.3.0 Status Report (2007-09-04)
Kai Tietz wrote: I'm sorry -- that doesn't really answer the question I was trying to ask. To be clear, if we're calling through a function pointer, we still need to be able to do the right thing, and in that case we don't have a FUNCTION_DECL. So, I don't understand how you can have a macro to control the calling convention that accepts a FUNCTION_DECL; I would think it would have to accept a FUNCTION_TYPE. Sorry, I think I missed your question. To make the macro OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no special reason for it. I deceided this to make it accepting a FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend. If this is a serious problem, of course I can move this to a FUNCTION_TYPE. Are there some special needs to have here FUNCTION_TYPE ? Yes, I think this -- and any other macros/hooks that affect calling convention -- must be based on FUNCTION_TYPEs, not FUNCTION_DECLs. Otherwise, we cannot properly support calling through a function pointer. From (one) type-theoretic perspective, types tell you what set of operations you can perform. You can't perform the operation call this function, putting its parameters in the usual place if the function doesn't want its parameters there; ergo, this must be a property of the type. Furthermore, I would argue that the attributes here should be recorded *only* on the type, in order to avoid duplication. That's not strictly speaking necessary, but calling conventions are certainly properly thought of as a property of types, not of declarations. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Joseph S. Myers wrote on 14.09.2007 00:09:49: On Thu, 13 Sep 2007, Michael Meissner wrote: In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then changing all of the targets. It might be better to have new macros (RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if the old macro is defined, code the new macro calling the earlier macro. This way you can avoid changing the other backends. Otherwise, you probably need to work with each maintainer to make sure you haven't broken their code. If you change the interface like that, the replacement should be a target hook in the target structure, not a target macro. On 14 August 2007 16:04, Kai Tietz wrote: AFAICS is RETURN_IN_MEMORY deprecated, isn't it. It seems to be there just by an incomplete move to TARGET_RETURN_IN_MEMORY (which allready has the additional parameter). Here's the 3.3.3 internals manual: 10.10.9 How Large Values Are Returned - When a function value's mode is `BLKmode' (and in some other cases), the value is not returned according to `FUNCTION_VALUE' (*note Scalar Return::). Instead, the caller passes the address of a block of memory in which the value should be stored. This address is called the structure value address. This section describes how to control returning structure values in memory. `RETURN_IN_MEMORY (TYPE)' A C expression which can inhibit the returning of certain function values in registers, based on the type of value. A nonzero value says to return the function value in memory, just as large structures are always returned. Here TYPE will be a C expression of type `tree', representing the data type of the value. Note that values of mode `BLKmode' must be explicitly handled by this macro. Also, the option `-fpcc-struct-return' takes effect regardless of this macro. On most systems, it is possible to leave the macro undefined; this causes a default definition to be used, whose value is the constant 1 for `BLKmode' values, and 0 otherwise. Do not use this macro to indicate that structures and unions should always be returned in memory. You should instead use `DEFAULT_PCC_STRUCT_RETURN' to indicate this. And now the current top-of-tree internals manual: 15.10.9 How Large Values Are Returned - When a function value's mode is `BLKmode' (and in some other cases), the value is not returned according to `TARGET_FUNCTION_VALUE' (*note Scalar Return::). Instead, the caller passes the address of a block of memory in which the value should be stored. This address is called the structure value address. This section describes how to control returning structure values in memory. -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE) This target hook should return a nonzero value to say to return the function value in memory, just as large structures are always returned. Here TYPE will be the data type of the value, and FNTYPE will be the type of the function doing the returning, or `NULL' for libcalls. Note that values of mode `BLKmode' must be explicitly handled by this function. Also, the option `-fpcc-struct-return' takes effect regardless of this macro. On most systems, it is possible to leave the hook undefined; this causes a default definition to be used, whose value is the constant 1 for `BLKmode' values, and 0 otherwise. Do not use this hook to indicate that structures and unions should always be returned in memory. You should instead use `DEFAULT_PCC_STRUCT_RETURN' to indicate this. So it looks like the documentation is already there; this is an incomplete transition, and I am just bringing the old back-compat macros up-to-date with the changed abi for the new target-hook version! Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: GCC 4.3.0 Status Report (2007-09-04)
Mark Mitchell wrote on 13.09.2007 20:42:25: Jan Hubicka wrote: Kai Tietz wrote: See http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV- MS-ABI-attributes-in-backend-tf4414541.html http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI- attributes-in-i386-may-before-stage--3-tf4428449.html Thanks for letting me know. I'm going to leave this to the x86 back-end maintainers. Global or middle end maintainer is needed for the first patch however. Good point. Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all calling-convention predicates ought to be looking at the type to support calling through function pointers? Hi Mark, This macro is used also in builtin's and libcalls subject where the FUNC_DECL is a null reference. Also in most places the FUNC_DECL is allready present. To avoid duplicate code to check and get the FUNC_TYPE by FUNC_DECL, I choose to pass the function declaration. Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: GCC 4.3.0 Status Report (2007-09-04)
Kai Tietz wrote: Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all calling-convention predicates ought to be looking at the type to support calling through function pointers? This macro is used also in builtin's and libcalls subject where the FUNC_DECL is a null reference. Also in most places the FUNC_DECL is allready present. To avoid duplicate code to check and get the FUNC_TYPE by FUNC_DECL, I choose to pass the function declaration. I'm sorry -- that doesn't really answer the question I was trying to ask. To be clear, if we're calling through a function pointer, we still need to be able to do the right thing, and in that case we don't have a FUNCTION_DECL. So, I don't understand how you can have a macro to control the calling convention that accepts a FUNCTION_DECL; I would think it would have to accept a FUNCTION_TYPE. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Kai Tietz wrote: See http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html Thanks for letting me know. I'm going to leave this to the x86 back-end maintainers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Kai Tietz wrote: See http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html Thanks for letting me know. I'm going to leave this to the x86 back-end maintainers. The changes are not completely trivial, but it is easy to verify that the default path (ie compiling sources not using new attributes) remains unchanged, so I would be happy to review the i386 specific patch after returning at Monday. Given also fact that this seems important for wine and other hybrid environments. Global or middle end maintainer is needed for the first patch however. Honza Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Michael Meissner wrote: One patch that got dropped on the floor was my patch to remove the dependency in the back ends of the way arguments are encoded, so that eventually for LTO we can swtich to using a vector instead of linked list. I think that could still goto 4.3, since it's already largely been reviewed. But, of course, we do need to make sure all the targets work. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Ramana Radhakrishnan wrote: I have a couple of patches that I submitted / intend to submit . One of them was submitted today regarding a small improvement to the auto-increment pass. I am not sure if this is suitable for stage3 if it is approved. http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01060.html We know that auto-increment handling has gotten worse in GCC 4.2/4.3, so if the relevant maintainers are happy with your patch from a technical perspective, then I think it qualifies as a bug fix. The other patch that we have for submission is relatively trivial and tries to be more precise with size costs for builtins while inlining. I guess that should be alright for stage3 . Yes, that sounds OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Jan Hubicka wrote: Kai Tietz wrote: See http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html Thanks for letting me know. I'm going to leave this to the x86 back-end maintainers. Global or middle end maintainer is needed for the first patch however. Good point. Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all calling-convention predicates ought to be looking at the type to support calling through function pointers? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
On Thu, Sep 13, 2007 at 10:45:56AM +0200, Jan Hubicka wrote: Kai Tietz wrote: See http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html Thanks for letting me know. I'm going to leave this to the x86 back-end maintainers. The changes are not completely trivial, but it is easy to verify that the default path (ie compiling sources not using new attributes) remains unchanged, so I would be happy to review the i386 specific patch after returning at Monday. Given also fact that this seems important for wine and other hybrid environments. Global or middle end maintainer is needed for the first patch however. In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then changing all of the targets. It might be better to have new macros (RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if the old macro is defined, code the new macro calling the earlier macro. This way you can avoid changing the other backends. Otherwise, you probably need to work with each maintainer to make sure you haven't broken their code. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
RE: GCC 4.3.0 Status Report (2007-09-04)
-Original Message- From: Mark Mitchell [mailto:[EMAIL PROTECTED] Sent: Thursday, September 13, 2007 2:37 PM To: Meissner, Michael; Mark Mitchell; GCC Subject: Re: GCC 4.3.0 Status Report (2007-09-04) Michael Meissner wrote: One patch that got dropped on the floor was my patch to remove the dependency in the back ends of the way arguments are encoded, so that eventually for LTO we can swtich to using a vector instead of linked list. I think that could still goto 4.3, since it's already largely been reviewed. But, of course, we do need to make sure all the targets work. I didn't hear back from you, so I checked in the machine independent and i386 parts in my SSE5 patch. Now, on to making the various ports still work with the change. -- Michael Meissner AMD, MS 83-29 90 Central Street Boxborough, MA 01719
Re: GCC 4.3.0 Status Report (2007-09-04)
Meissner, Michael wrote: I didn't hear back from you, so I checked in the machine independent and i386 parts in my SSE5 patch. Now, on to making the various ports still work with the change. All right; sounds good. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
On Thu, 13 Sep 2007, Michael Meissner wrote: In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then changing all of the targets. It might be better to have new macros (RETURN_IN_MEMORY_ABI, OUTGOING_REG_PARM_STACK_SPACE_ABI), and if the old macro is defined, code the new macro calling the earlier macro. This way you can avoid changing the other backends. Otherwise, you probably need to work with each maintainer to make sure you haven't broken their code. If you change the interface like that, the replacement should be a target hook in the target structure, not a target macro. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.3.0 Status Report (2007-09-04)
I have two patch may be worth to enter into 4.3 at stage 2. Jan and I tried to ping the first part now about some time and we didn't got a comment or approval for them. See http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html Cheers, i.A. Kai Tietz | (\_/) This is Bunny. Copy and paste Bunny | (='.'=) into your signature to help him gain | ()_() world domination. -- OneVision Software Entwicklungs GmbH Co. KG Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050 Handelsregister: HRA 6744, Amtsgericht Regensburg Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: Ulrike Döhler, Manuela Kluger
Re: GCC 4.3.0 Status Report (2007-09-04)
Hi, I apologize for the late response to your mail but I sort of did these patches up recently . I have a couple of patches that I submitted / intend to submit . One of them was submitted today regarding a small improvement to the auto-increment pass. I am not sure if this is suitable for stage3 if it is approved. http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01060.html The other patch that we have for submission is relatively trivial and tries to be more precise with size costs for builtins while inlining. I guess that should be alright for stage3 . cheers Ramana We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. Quality === Priority # --- P1 43 P2118 P3 4 Total 165 Obviously, that's rather more P1s than we'd like. As I mentioned in my previous status report, of particular concern is that we've got a lot of 4.3-only P1s. I'm sure many of those won't be too hard to fix, but we still need to go and fix them. I'm concerned about getting into a situation where we say well, 4.2 has some bugs, but all of those are fixed in 4.3 and then realize that oh, well, 4.3 has different bugs too, but those are all fixed in 4.4 and so forth. Previous Report === http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 -- Ramana Radhakrishnan
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. I have a bunch of tiny patches, nevertheless all Stage 2 material, as they add new features: __artificial__ attribute (except the builtins.c hunk which is addressed differently): http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html __builtin_va_arg_pack_len () addition: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html redundant zero store elimination optimization (simplistic version, but nevertheless is able to trigger many times during gcc bootstrap): http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html diagnostic changes to print virtual call stack: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html __error_decl__ and __warning_decl__ attributes: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html Jakub
RE: GCC 4.3.0 Status Report (2007-09-04)
Jagasia, Harsha wrote: I still plan to submit a patch for the x86 target cost model tuning. Assuming that this isn't too dramatic, I'll leave approval of that during Stage 3 to the x86 back-end maintainers. Thanks. The patch involves some x86 back-end bits, which Honza has already approved and some fixes to the vectorizer, which Dorit has mostly approved (I am waiting on her approval for my last mail). My plan is to submit the patch today with the changes Dorit has recommended. I may end up splitting it such that most of the patch makes it today and one bug fix for the vectorizer makes it in stage 3. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote: Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. It has only been four days since I posted the patch, but I am waiting for a review of the new interference graph representation: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00529.html In addition to the powerpc64-linux bootstrap and regtesting I did, Seongbae bootstrapped and regtested this on x86_64 with no regressions as well as running it on SPEC with no runtime or compile time regressions. Peter
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. Quality === Priority # --- P1 43 P2118 P3 4 Total 165 Obviously, that's rather more P1s than we'd like. As I mentioned in my previous status report, of particular concern is that we've got a lot of 4.3-only P1s. I'm sure many of those won't be too hard to fix, but we still need to go and fix them. I'm concerned about getting into a situation where we say well, 4.2 has some bugs, but all of those are fixed in 4.3 and then realize that oh, well, 4.3 has different bugs too, but those are all fixed in 4.4 and so forth. One patch that got dropped on the floor was my patch to remove the dependency in the back ends of the way arguments are encoded, so that eventually for LTO we can swtich to using a vector instead of linked list. As I recall, I had fixed all backends except for the SPU, which I needed to investigate the builtins. Now that SSE5 is winding down, I can go back to this patch. Given it has been reviewed in this list, I will leave it to Mark to decide whether it should go into 4.3 or 4.4. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA [EMAIL PROTECTED]
Re: GCC 4.3.0 Status Report (2007-09-04)
Hi, thanks for looking at the patch. On Sun, Sep 09, 2007 at 11:42:55AM -0700, Mark Mitchell wrote: Martin Jambor wrote: Well, there's mine :-) Specifically, its the Switch initializations conversion: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html Do you have an FSF copyright assignment on file? This patch is big enough that we would not be able to include it without that. Yes, I do, see http://misc.jamborm.net/Jambor305799.pdf I see one technical change that should be made. In particular, please change: +/* We never create arrays larger than the following constant (given in number + of elements). */ +#define MAX_ARRAY_RANGE 0x2000 + +/* We never create arrays if the number of branches is not at least the range + divided by the following constant. */ +#define MAX_RANGE_BRANCH_RATIO 8 to use the --param mechanism. Our policy is to have *no* magic numbers for these kinds of things. It's easy enough to allow users to use --param to set the values, and that makes it easy for people (often the compiler developers themselves) to experiment with the values to help fine-tune the defaults. OK, I have changed the patch accordingly (and added some documentation that was missing last time) and am currently re-testing it. I expect to post the new version to the list tonight. Martin
Re: GCC 4.3.0 Status Report (2007-09-04)
Jakub Jelinek wrote: I have a bunch of tiny patches, nevertheless all Stage 2 material, as they add new features: I'd like a middle-end maintainer to review this one: redundant zero store elimination optimization (simplistic version, but nevertheless is able to trigger many times during gcc bootstrap): http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00663.html That seems like a nice optimization. It was interesting to see how many places this hit in GCC. I didn't see any data about performance improvements on benchmarks (e.g., SPEC), or code-size improvements (e.g., CSiBE), but it sure can't hurt. Unfortunately, I think there are enough issues around most of the rest of these patches that we should wait for 4.4. In particular, all of these: __artificial__ attribute (except the builtins.c hunk which is addressed differently): http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02300.html __builtin_va_arg_pack_len () addition: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00675.html __error_decl__ and __warning_decl__ attributes: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00876.html add extensions of one kind or another to GCC, and there has been some discussion about each of them. I think we have to be very careful with these things; once they go out in a release, we live with them forever. However, I do hereby acknowledge that these were submitted before Stage 2 ended, and, as per our guidelines, if these patches are approved, they can still go in. This one: diagnostic changes to print virtual call stack: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00868.html looks like it would have a major effect on consumers of GCC output. As you say: The tools that parse this will need changing anyway to do something reasonable with it I think we should consider GCC diagnostic a defined, machine-readable format and that we should modify it only in backwards-compatible ways. Or, make incompatible changes only under control of an option or environment variable. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Peter Bergner wrote: On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote: Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. It has only been four days since I posted the patch, but I am waiting for a review of the new interference graph representation: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00529.html This certainly seems an excellent thing. If nobody else reviews this, I will do so -- but I hope that one of our busy middle-end maintainers will make time. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Martin Jambor wrote: Well, there's mine :-) Specifically, its the Switch initializations conversion: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html Do you have an FSF copyright assignment on file? This patch is big enough that we would not be able to include it without that. Jakub Jelinek had a few comments and I changed the patch according to them. After that, nothing much happened. If any maintainer likes the patch, please commit it as I do not have write access to svn. OTOH, if there are any further concerns, please let me know. I see one technical change that should be made. In particular, please change: +/* We never create arrays larger than the following constant (given in number + of elements). */ +#define MAX_ARRAY_RANGE 0x2000 + +/* We never create arrays if the number of branches is not at least the range + divided by the following constant. */ +#define MAX_RANGE_BRANCH_RATIO 8 to use the --param mechanism. Our policy is to have *no* magic numbers for these kinds of things. It's easy enough to allow users to use --param to set the values, and that makes it easy for people (often the compiler developers themselves) to experiment with the values to help fine-tune the defaults. Other than that, the patch looks pretty good to me. However, I'd like a middle-end maintainer to review the patch. Ian, Diego, Roger, would one of you please take a look? Is there any reason to think this patch might generate worse code on some processors or in some modes? For example, while this patch seems it's definitely a code-size win for dense switch statements, do we need some kind of cost model to tell us whether it's a code-size win with less dense switch statements? Do we want want separate params when we're operating under -Os from when we're operating under -O2? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Rask Ingemann Lambertsen wrote: On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html This patch is OK. There may be machine descriptions that, for whatever reason, only do something clever with a + b b; they will now lose. But, those machine descriptions were odd anyhow; logically, they should handle both a + b a and a + b b the same way. So, your patch seems like a good improvement; as you say, it gives the back end fewer cases to optimize. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Richard Guenther wrote: There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. This is an optimization pass which leads to dramatically better code on at least one SPEC benchmark. Ian, Roger, Diego, would one of you care to review this? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Jan Hubicka wrote: I am still planning to do some retuning of inliner (our inline limits wasn't revisited for inclusion of SSA optimizers). Assuming that the tuning is essentially twiddling constants, I'm not overly worried. If you're planning to adjust the algorithms substantially, then I'd be more concerned. Let me know. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Jagasia, Harsha wrote: I still plan to submit a patch for the x86 target cost model tuning. Assuming that this isn't too dramatic, I'll leave approval of that during Stage 3 to the x86 back-end maintainers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
This is an optimization pass which leads to dramatically better code on at least one SPEC benchmark. Ian, Roger, Diego, would one of you care to review this? My concern is that as formulated, conditional store elimination is not always a win. Transforming if (cond) *p = x; into tmp = *p; if (cond) tmp = x; *p = tmp; on it's own, effectively transforms a conditional write to memory into an unconditional write to memory. On many platforms, even x86, this a pessimization. For example, the Intel Architecture Optimization Manual, available at ftp://download.intel.com/design/PentiumII/manuals/24281603.PDF in section 3.5.5 Write Allocation Effects, actually recommends the inverse transformation. On page 3-21 they show how the Sieve of Erastothenes benchmark can be sped up on Pentium class processors by transforming the line array[j] = 0; into the equivalent if (array[j] != 0) array[j] = 0; i.e. by introducing conditional stores. The significant observation with Michael Matz's extremely impressive 26% improvement on 456.hmmer is the interaction between this transformation with other passes, that allow the conditional store to be hoisted out of a critical loop. By reading the value into a tmp before the loop, conditionally storing to the register tmp in the loop, then unconditionally writing the result back afterwards, we dramatically reduce the number of memory writes, rather than increase them as when this transformation is applied in isolation. I think the correct fix is not to apply this transformation everywhere, but to correctly identify those loop cases where it helps and perform the loop transformation there. i.e. conditional induction variable identification, hoisting and sinking needs to be improved instead of pessimizing code to a simpler form that allows our existing flawed passes to trigger. I do very much like the loop-restricted version of this transformation, and it's impressive impact of HMMR (whose author Sean Eddy is a good friend). Perhaps Mark might give revised versions of this patch special dispensation to be applied in stage 3. I'd not expect any correctness issues/bugs, just performance trade-offs that need to be investigated. Perhaps we should even apply this patch as is during stage 2, and allow the potential non-loop performance degradations to be addressed as follow-up patches and therefore regression fixes suitable for stage 3? Congratulations again to Michael for this impressive performance improvement. Roger -- Roger Sayle, Ph.D. OpenEye Scientific Software, Suite #D, 9 Bisbee Court, Santa Fe, New Mexico, 87508.
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/9/07, Roger Sayle [EMAIL PROTECTED] wrote: This is an optimization pass which leads to dramatically better code on at least one SPEC benchmark. Ian, Roger, Diego, would one of you care to review this? Btw, diego already approved the patch. My concern is that as formulated, conditional store elimination is not always a win. Transforming if (cond) *p = x; into tmp = *p; if (cond) tmp = x; *p = tmp; on it's own, effectively transforms a conditional write to memory into an unconditional write to memory. The pass currently only does the transformation if there is a preceding load already. Because I raised this same issue ;) On many platforms, even x86, this a pessimization. For example, the Intel Architecture Optimization Manual, available at ftp://download.intel.com/design/PentiumII/manuals/24281603.PDF in section 3.5.5 Write Allocation Effects, actually recommends the inverse transformation. On page 3-21 they show how the Sieve of Erastothenes benchmark can be sped up on Pentium class processors by transforming the line array[j] = 0; into the equivalent if (array[j] != 0) array[j] = 0; i.e. by introducing conditional stores. I suppose this is no longer true on modern processors? I think the pass may undo this case. But I'm also not sure we should worry about this. The significant observation with Michael Matz's extremely impressive 26% improvement on 456.hmmer is the interaction between this transformation with other passes, that allow the conditional store to be hoisted out of a critical loop. By reading the value into a tmp before the loop, conditionally storing to the register tmp in the loop, then unconditionally writing the result back afterwards, we dramatically reduce the number of memory writes, rather than increase them as when this transformation is applied in isolation. I think the correct fix is not to apply this transformation everywhere, but to correctly identify those loop cases where it helps and perform the loop transformation there. i.e. conditional induction variable identification, hoisting and sinking needs to be improved instead of pessimizing code to a simpler form that allows our existing flawed passes to trigger. I do very much like the loop-restricted version of this transformation, and it's impressive impact of HMMR (whose author Sean Eddy is a good friend). Perhaps Mark might give revised versions of this patch special dispensation to be applied in stage 3. I'd not expect any correctness issues/bugs, just performance trade-offs that need to be investigated. Perhaps we should even apply this patch as is during stage 2, and allow the potential non-loop performance degradations to be addressed as follow-up patches and therefore regression fixes suitable for stage 3? I think it should be straight forward to apply this transformation in loops only - requiring analysis that the resulting loads and stores are loop invariant would of course require more work. Given the above restriction we apply already, do you hold your objections or would you consider the simple loop improvement? Thanks, Richard.
Re: GCC 4.3.0 Status Report (2007-09-04)
Richard Guenther wrote: On 9/9/07, Roger Sayle [EMAIL PROTECTED] wrote: This is an optimization pass which leads to dramatically better code on at least one SPEC benchmark. Ian, Roger, Diego, would one of you care to review this? Btw, diego already approved the patch. I apologize for muddying the waters, then. Roger, thank you for reviewing. I'll leave Richard G., Roger, and Diego to work out what best to do; please let me know if I can help. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Jan Hubicka wrote: I am still planning to do some retuning of inliner (our inline limits wasn't revisited for inclusion of SSA optimizers). Assuming that the tuning is essentially twiddling constants, I'm not overly worried. If you're planning to adjust the algorithms substantially, then I'd be more concerned. Let me know. Thanks, the plan is to essentially twiddle the constants (reduce limits since we now see more realistic program estimates). There is similar situation with the currently discussed SSE conversion codegen - I've comitted the basic codegen changes today, but we need to run some benchmarks to figure out setting for generic model. I hope this would be acceptable too... CPU2006 takes a lot of time :( Honza
Re: GCC 4.3.0 Status Report (2007-09-04)
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217.html It's blocking work on the additional optimization requested by the customer in comment 11: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315#c11 -- Rask Ingemann Lambertsen
Re: GCC 4.3.0 Status Report (2007-09-04)
Hi, On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. Well, there's mine :-) Specifically, its the Switch initializations conversion: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html Jakub Jelinek had a few comments and I changed the patch according to them. After that, nothing much happened. If any maintainer likes the patch, please commit it as I do not have write access to svn. OTOH, if there are any further concerns, please let me know. Sorry for a late reply, I lagged behind the mailing list for a few days. Thanks, Martin
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/5/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. Richard.
Re: GCC 4.3.0 Status Report (2007-09-04)
There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. As much as I like the idea, wasn't get_non_trapping considered unsafe? Paolo
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/6/07, Paolo Bonzini [EMAIL PROTECTED] wrote: There is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html for example, which is not suitable for stage3. As much as I like the idea, wasn't get_non_trapping considered unsafe? Only if you tried to preserve this information across passes. This updated patch computes this information just for the local transformation. Richard.
Re: GCC 4.3.0 Status Report (2007-09-04)
On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. The patches to make the new -Wconversion work with decimal float types are still pending review. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html Unfortunately, even if I could skip sleep for one night to get some extra time, I won't have the means needed to test them, update them to current trunk or commit them before Sep 10th. Perhaps in two or three weeks I could... By the way, have the patches for FixedPointArithmetic added Wconversion support? I guess that will make the patches above to not apply cleanly anymore. Cheers, Manuel.
Re: GCC 4.3.0 Status Report (2007-09-04)
Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? I am still planning to do some retuning of inliner (our inline limits wasn't revisited for inclusion of SSA optimizers). I am now waiting on Diego to decide on http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00318.html that makes the metrics looks quite significandly different. Then I will run few tests on our C++/SPEC tester in hope that we can now significandly cut some of the limits previously pushed up by the tests with large abstraction (DLV/Tramp3d) and speedup compilation/reduce binaries. It will probably take more than 2 days, but I hope it is acceptable for early stage3. I will be on conference from 10th to 16th, but I expect to be able to do the benchmarking needed. Honza
Re: GCC 4.3.0 Status Report (2007-09-04)
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote: We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? I still plan to submit the loop distribution pass. Sebastian
RE: GCC 4.3.0 Status Report (2007-09-04)
Manuel López-Ibáñez wrote: On 05/09/07, Mark Mitchell [EMAIL PROTECTED] wrote: Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. The patches to make the new -Wconversion work with decimal float types are still pending review. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html Unfortunately, even if I could skip sleep for one night to get some extra time, I won't have the means needed to test them, update them to current trunk or commit them before Sep 10th. Perhaps in two or three weeks I could... By the way, have the patches for FixedPointArithmetic added Wconversion support? I guess that will make the patches above to not apply cleanly anymore. Not yet. After I get the remaining patches (7, 8, 9, 10) checked in, I will see how much work is needed to support Wconversion for fixed-point types. Thanks! Regards, Chao-ying
RE: GCC 4.3.0 Status Report (2007-09-04)
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote: We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? I still plan to submit a patch for the x86 target cost model tuning. Harsha
Re: GCC 4.3.0 Status Report (2007-09-04)
DJ Delorie wrote: Also, we never decided if undo was worth the extra overhead. The code is in the patch, but ifdef'd out. URL, please? http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01317.html It looks to me like this probably isn't quite ready for prime-time; I do think we'd want to make the push/pop stuff fully reliable, including warnings emitted from the middle-end. That's not an over-my-dead-body; if other people feel differently, I'm happy to discuss. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
It looks to me like this probably isn't quite ready for prime-time; I do think we'd want to make the push/pop stuff fully reliable, including warnings emitted from the middle-end. push-pop around functions won't be reliable until we have the file location thing, so we can map a file:line to a point in the chain of changes to the diagnostic classification tree. This is no different than our current disclaimer that pragma diagnostic changes after the first function definition are not supported.
GCC 4.3.0 Status Report (2007-09-04)
Summary === We are closing in on Stage 3, previously announced for September 10th. At this point, I'm not aware of any reason to delay that date. Are there any Stage 2 patches that people don't think will be submitted by that point? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. Quality === Priority # --- P1 43 P2118 P3 4 Total 165 Obviously, that's rather more P1s than we'd like. As I mentioned in my previous status report, of particular concern is that we've got a lot of 4.3-only P1s. I'm sure many of those won't be too hard to fix, but we still need to go and fix them. I'm concerned about getting into a situation where we say well, 4.2 has some bugs, but all of those are fixed in 4.3 and then realize that oh, well, 4.3 has different bugs too, but those are all fixed in 4.4 and so forth. Previous Report === http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
Mark Mitchell [EMAIL PROTECTED] writes: Are there Stage 1 or Stage 2 patches in need of review? Do you want the diagnostic pragma push/pop patch in?
Re: GCC 4.3.0 Status Report (2007-09-04)
DJ Delorie wrote: Mark Mitchell [EMAIL PROTECTED] writes: Are there Stage 1 or Stage 2 patches in need of review? Do you want the diagnostic pragma push/pop patch in? In, if it works. :-) URL, please? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
In, if it works. :-) Well, it does what it's supposed to do. Whether that's a works in the grand scheme of things is still debatable :-) I'd still need to write testcases and a changelog, as I was posing it as a what-if-example so far. Also, we still don't guarantee proper operation in all cases if you change diagnostics after defining a function. That will have to wait until we have the single-int-location thing. Also, we never decided if undo was worth the extra overhead. The code is in the patch, but ifdef'd out. URL, please? http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01317.html
