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: "Bin Cheng" <bin dot cheng at arm dot com>
- To: <gcc-patches at gcc dot gnu dot org>
- Cc: "'Jeff Law'" <law at redhat dot com>, "'Joern Rennecke'" <joern dot rennecke at embecosm dot com>
- Date: Sun, 7 Apr 2013 11:15:59 +0800
- Subject: RE: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
- References: <000501ce2926$88ffe1d0$9affa570$ at firstname.lastname@example.org> <20130325085252 dot 0ybsd4exs0okw0oc-nzlynne at webmail dot spamcop dot net> <002501ce29fc$83449390$89cdbab0$ at email@example.com>
> -----Original Message-----
> 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
> > -----Original Message-----
> > From: Joern Rennecke [mailto:email@example.com]
> > Sent: Monday, March 25, 2013 8:53 PM
> > To: Bin Cheng
> > Cc: firstname.lastname@example.org
> > Subject: Re: [PATCH GCC]Relax the probability condition in CE pass
> > when optimizing for code size
> > Quoting Bin Cheng <email@example.com>:
> > > 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 <firstname.lastname@example.org>
> > >
> > > * 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,
> > 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.
> Hi Jeff,
> This is based on your heuristic tuning in ifcvt, would you help us on this
> issue with some suggestions?