This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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-owner@gcc.gnu.org [mailto:gcc-patches-owner@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.rennecke@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.cheng@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.cheng@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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]