RE: [PATCH] Implement ‘optnone’ attribute semantics

[Robinson, Paul]

New patch #2 (passes) and #3 (backend).
--paulr

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Robinson, Paul
Sent: Monday, November 18, 2013 11:53 AM
To: Chandler Carruth
Cc: llvm-commits at cs.uiuc.edu commits (llvm-commits at cs.uiuc.edu)
Subject: RE: [PATCH] Implement ‘optnone’ attribute semantics

We looked at having each pass decide whether to check ‘optnone’, and it seemed that refactoring that logic into PM was cleaner.  Also, PM seemed like the right place to make decisions about what passes would run…. Without PM involved, the chunk of code in each pass is more intrusive.  But we can do that.
--paulr

From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: Monday, November 18, 2013 12:17 AM
To: Robinson, Paul
Cc: llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu> commits (llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>)
Subject: Re: [PATCH] Implement ‘optnone’ attribute semantics


On Wed, Nov 13, 2013 at 4:09 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
Patch #2 deals with skipping optimization passes for 'optnone'
functions.  This is probably the piece that has caused the most angst.
We tried to minimize the fiddling with the dreaded Pass Manager, and
made as straightforward and simple a change as we could come up with
that got the job done.  That is:

We introduce a 'bool mustAlwaysRun()' method on passes, and say that
an 'optnone' function doesn't run any function IR, loop, or basic
block pass, unless that pass is marked 'mustAlwaysRun.'  The default
for 'mustAlwaysRun' is true, so we explicitly turn it off for all the
Transform passes that we do not want to run on an 'optnone' function.
This is kind of tedious but is a mostly mechanical change.

Note that module-level passes will still consider 'optnone' functions.

I don't really like this approach.

In re-working the pass manager stuff it is really desirable that the pass interface narrow. And if you're going to have to update each transform pass to handle this attribute anyways, it would seem better to just go into each pass's run method and add an early exit if the attribute is set. Did folks see any problems with doing that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131119/e00fd4dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2-optnone-Passes.patch
Type: application/octet-stream
Size: 25391 bytes
Desc: 2-optnone-Passes.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131119/e00fd4dc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3-optnone-CodeGen.patch
Type: application/octet-stream
Size: 6961 bytes
Desc: 3-optnone-CodeGen.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131119/e00fd4dc/attachment-0001.obj>