[PATCH] [AArch64] Enable partial unrolling and runtime unrolling for AArch64 target

[Bob Wilson]

> On Sep 9, 2014, at 11:40 AM, Eric Christopher <echristo at gmail.com> wrote:
> 
> 
> 
> On Tue, Sep 9, 2014 at 8:57 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
> ----- Original Message -----
> > From: "Renato Golin" <renato.golin at linaro.org <mailto:renato.golin at linaro.org>>
> > To: "Tilmann Scheller" <t.scheller at samsung.com <mailto:t.scheller at samsung.com>>
> > Cc: reviews+D5148+public+3607c133967fc2d2 at reviews.llvm.org <mailto:reviews%2BD5148%2Bpublic%2B3607c133967fc2d2 at reviews.llvm.org>, "LLVM Commits" <llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>>
> > Sent: Tuesday, September 9, 2014 9:33:39 AM
> > Subject: Re: [PATCH] [AArch64] Enable partial unrolling and runtime unrolling for AArch64 target
> >
> > On 9 September 2014 15:15, Tilmann Scheller <t.scheller at samsung.com <mailto:t.scheller at samsung.com>>
> > wrote:
> > > can we make sure this is enabled only with -O3 rather than -O2/-Os
> > > though?
> > > (at least until the code size regressions are fixed)
> >
> > Good point!
> 
> In case this helps: The way this works is that functions compiled with -Os get the 'optsize' attribute added. The UnrollingPreferences structure has both an PartialThreshold and an PartialOptSizeThreshold parameter that can be set accordingly.
> 
> Right, 50% is still a pretty large code size increase even for O2, so O3 might be best here.

I will go one step further.

50% code size regression, even on just a few tests, is completely unacceptable for -O2.

For -O3, it might be tolerable if it provides a very significant performance win to compensate. It doesn’t sound like the performance is really that compelling, though. I think this should be under the control of a separate option, not enabled by default for -O3, until the code size regressions get fixed.

> 
> Kevin: Are you going to work on the code size issues or...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140909/cff50ef4/attachment.html>