This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
- From: Jeff Law <law at redhat dot com>
- To: Bin Cheng <bin dot cheng at arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "'Joern Rennecke'" <joern dot rennecke at embecosm dot com>
- Date: Mon, 08 Apr 2013 07:32:18 -0600
- Subject: Re: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
- References: <000501ce2926$88ffe1d0$9affa570$ at email@example.com> <20130325085252 dot 0ybsd4exs0okw0oc-nzlynne at webmail dot spamcop dot net> <002501ce29fc$83449390$89cdbab0$ at firstname.lastname@example.org> <000001ce333e$3c8ff7a0$b5afe6e0$ at email@example.com>
On 04/06/2013 09:15 PM, Bin Cheng wrote:
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.
From: firstname.lastname@example.org [mailto:email@example.com]
Behalf Of Bin Cheng
Sent: Tuesday, March 26, 2013 4:33 PM
To: 'Joern Rennecke'
Cc: firstname.lastname@example.org; 'Jeff Law'
Subject: RE: [PATCH GCC]Relax the probability condition in CE pass when
optimizing for code size
From: Joern Rennecke [mailto:email@example.com]
Sent: Monday, March 25, 2013 8:53 PM
To: Bin Cheng
Subject: Re: [PATCH GCC]Relax the probability condition in CE pass
when optimizing for code size
Quoting Bin Cheng <firstname.lastname@example.org>:
During the work I observed passes before combine might interfere
with CE pass, so this patch is enabled for ce2/ce3 after combination
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 <email@example.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
they can be tweaked by ports and/or by a user/ML learning framework
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
depends on specific target/application.
This is based on your heuristic tuning in ifcvt, would you help us on this
issue with some suggestions?