[cfe-dev] [LLVMdev] [RFC] add Function Attribute to disable optimization

[Andrea_DiBiagio at sn.scee.net]

> From: Sean Silva <silvas at purdue.edu>
> Here are the problems found:
> 1) It is not safe to disable some transform passes in the backend.
> It looks like there are some unwritten dependences between passes and
> disrupting the sequence of passes to run may result in unexpected 
crashes
> and/or assertion failures;
> 
> This sounds like a bug. It's probably worth bringing up as its own 
> discussion on llvmdev if it is extremely prevalent, or file PR's (or
> send patches fixing it!) if it is just a few isolated cases.

It looks like the problem was in my code and it was caused by the lack of 
update on the set of preserved analysis; as soon as the problem was fixed, 
all the unexpected failures disappeared.

> 2)  The fact that pass managers are not currently designed to support
> per-function optimization makes it difficult to find a reasonable way to
> implement this new feature.
> 
> About point 2. the Idea that came in my mind consisted in making passes
> aware of the 'noopt' attribute.
> In my experiment:
>  - I added a virtual method called 'mustAlwaysRun' in class Pass that
> 'returns true if it is not safe to disable this pass'.
> If a pass does not override the default implementation of that method,
> then by default it will always return true (i.e. the pass "must
> always run" pass even when attribute 'noopt' is specified).
>  - I then redefined in override that method on all the optimization 
passes
> that could have been safely turned off when attribute noopt was present.
> In my experiment, I specifically didn't disable Module Passes;
>  - Then I modified the 'doInitialize()' 'run*()' and 'doFinalize' 
methods
> in Pass Manger to check for both the presence of attribute noopt AND the
> value returned by method 'mustAlwaysRun' called on the current pass
> instance.
> 
> That experiment seemed to "work" on a few tests and benchmarks.
> However:
>  a) 'noopt' wouldn't really imply no optimization, since not all codegen
> optimization passes can be safely disabled. As a result, the assembly
> produced for noopt functions had few differences with respect to the
> assembly generated for the same functions at -O0;
>  b) I don't particularly like the idea of making passes "aware" of the
> 'noopt' attribute. However, I don't know if there is a reasonable way to
> implement the noopt attribute without having to re-design how pass
> managers work.
> 
> A redesign of the pass manager has been on the table for a while and
> the need seems more pressing daily. Definitely make sure that this 
> use case is brought up in any design discussions for the new pass 
manager.
> 
> -- Sean Silva

Sure, I will definitely bring up this as soon as there will be a 
discussion about the pass manager.

As I mentioned in my previous post, there could be a way to implement the 
'noopt' attribute without having to redesign the pass manager.
However it would require that we explicitly mark function passes that are 
expected to not run on a function marked as 'noopt'. That would guide the 
pass manager when selecting which passes to initialize/run/finalize on a 
'noopt' function.

What I don't like about that approach is the fact that passes would know 
about the noopt flag. Not only it would require changes in most of the 
already existent passes, but also it would force people who develop 
optimization passes to know about the existence of 'noopt' when they 
define their pass..

My questions are: 
would it be reasonable/acceptable at this point to implement this proposal 
before the pass manager is redesigned?
If so, a solution like the one described above would be acceptable? Or are 
there better solutions?

Any feedback (either good or bad) would be really appreciated at this 
point.

Thanks,
Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group

**********************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify postmaster at scee.net
This footnote also confirms that this email message has been checked for 
all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United 
Kingdom
Registered in England: 3277793
**********************************************************************

P Please consider the environment before printing this e-mail