Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
On 04/06/2013 09:15 PM, Bin Cheng wrote: -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Tuesday, March 26, 2013 4:33 PM To: 'Joern Rennecke' Cc: gcc-patches@gcc.gnu.org; 'Jeff Law' Subject: RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size -Original Message- From: Joern Rennecke [mailto:joern.renne...@embecosm.com] Sent: Monday, March 25, 2013 8:53 PM To: Bin Cheng Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size Quoting Bin Cheng bin.ch...@arm.com: During the work I observed passes before combine might interfere with CE pass, so this patch is enabled for ce2/ce3 after combination pass. It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk? There are bound to be target and application specific variations on which scaling factors work best. 2013-03-25 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. It would make more sense to pass in the scale factor as a an argument to if_convert. And get the respective values from a set of gcc parameters, so they can be tweaked by ports and/or by a user/ML learning framework (e.g. Milepost) supplying the appropriate --param option. I agree it would be more flexible to pass the factor as parameter, but not sure how useful to users it will be because: firstly it has already been target specific by the BRANCH_COST heuristic; for code size, the heuristic should be tuned to achieve an overall good results, I doubt to which extend it depends on specific target/application. Hi Jeff, This is based on your heuristic tuning in ifcvt, would you help us on this issue with some suggestions? Not sure what you need from me. It seems to me that having the scaling factor be dependent on optimizing for size vs optimizing for speed makes sense. The only question is whether or not it's important enough to be a knob the user can turn -- I've got no strong opinions on that. jeff
RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Tuesday, March 26, 2013 4:33 PM To: 'Joern Rennecke' Cc: gcc-patches@gcc.gnu.org; 'Jeff Law' Subject: RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size -Original Message- From: Joern Rennecke [mailto:joern.renne...@embecosm.com] Sent: Monday, March 25, 2013 8:53 PM To: Bin Cheng Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size Quoting Bin Cheng bin.ch...@arm.com: During the work I observed passes before combine might interfere with CE pass, so this patch is enabled for ce2/ce3 after combination pass. It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk? There are bound to be target and application specific variations on which scaling factors work best. 2013-03-25 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. It would make more sense to pass in the scale factor as a an argument to if_convert. And get the respective values from a set of gcc parameters, so they can be tweaked by ports and/or by a user/ML learning framework (e.g. Milepost) supplying the appropriate --param option. I agree it would be more flexible to pass the factor as parameter, but not sure how useful to users it will be because: firstly it has already been target specific by the BRANCH_COST heuristic; for code size, the heuristic should be tuned to achieve an overall good results, I doubt to which extend it depends on specific target/application. Hi Jeff, This is based on your heuristic tuning in ifcvt, would you help us on this issue with some suggestions? Ping.
RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
-Original Message- From: Joern Rennecke [mailto:joern.renne...@embecosm.com] Sent: Monday, March 25, 2013 8:53 PM To: Bin Cheng Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size Quoting Bin Cheng bin.ch...@arm.com: During the work I observed passes before combine might interfere with CE pass, so this patch is enabled for ce2/ce3 after combination pass. It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk? There are bound to be target and application specific variations on which scaling factors work best. 2013-03-25 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. It would make more sense to pass in the scale factor as a an argument to if_convert. And get the respective values from a set of gcc parameters, so they can be tweaked by ports and/or by a user/ML learning framework (e.g. Milepost) supplying the appropriate --param option. I agree it would be more flexible to pass the factor as parameter, but not sure how useful to users it will be because: firstly it has already been target specific by the BRANCH_COST heuristic; for code size, the heuristic should be tuned to achieve an overall good results, I doubt to which extend it depends on specific target/application. Hi Jeff, This is based on your heuristic tuning in ifcvt, would you help us on this issue with some suggestions? Thanks very much.
Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
Quoting Bin Cheng bin.ch...@arm.com: During the work I observed passes before combine might interfere with CE pass, so this patch is enabled for ce2/ce3 after combination pass. It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk? There are bound to be target and application specific variations on which scaling factors work best. 2013-03-25 Bin Cheng bin.ch...@arm.com * ifcvt.c (ifcvt_after_combine): New static variable. It would make more sense to pass in the scale factor as a an argument to if_convert. And get the respective values from a set of gcc parameters, so they can be tweaked by ports and/or by a user/ML learning framework (e.g. Milepost) supplying the appropriate --param option.
