[llvm] r189101 - Add function attribute 'optnone'.

[Greg_Bedwell at sn.scee.net]

Hi.  Just for full disclosure, I'm a colleague of Andrea's jumping into 
the discussion here :-).

> it sounds like you want GCC's recently added -Og.  Sorry to say this, 
but
> optnone sounds like a bad way to solve this problem to me.  Personally I
> think you should remove optnone and instead work on improving the
> interaction between the -O1 optimizers and debug info.  Maybe if 
optimization
> levels become an attribute attached to functions, then we could have a
> -Og attribute and teach the optimizers not to do optimizations that 
> unavoidably
> play badly with debug info.  But for the moment -O1 is the closest 
> thing we have
> to -Og.
> 

I agree that we need to continue to make improvements to the debug 
experience in fully optimized builds, and this is another area which we 
are attacking the problem from, and there's certainly a lot we can do to 
make things "better", but realistically no matter how much work we do, 
there's no way we're ever going to make O2 debugging as good as O0 
debugging so I think it is worth looking at other ways to help out our 
users (as I read it I think that there doesn't seem to be any argument 
against this particular point). 

On our own compiler for a previous platform we implemented something 
similar to -Og.  In my experience it's sometimes useful as one of the 
tools available to our users in specific contexts such as some of the non 
performance-critical libraries sitting on the periphery of a game, but 
often the performance was just not there.  Anything less than -O2/-O3 is 
just not an option for our users when dealing with low-level game engine 
code, as Sean says.  Right now they usually just have to resort to 
debugging at assembly level.  I found these blog posts that sum up the 
sort of pain that they go through doing this:-):

http://www.altdevblogaday.com/2011/01/25/tips-and-tricks-for-debugging-optimized-code/ 

http://www.altdevblogaday.com/2011/07/25/debugging-techniques-for-optimized-ppc-builds/ 

http://www.altdevblogaday.com/2011/01/16/looks-like-im-up/ 

For us, the big advantage of the optnone approach is that it will give our 
users a new, more precise tool to add to their arsenal of debugging 
techniques.  Often they know *where* to look, but the actual process of 
doing it is more painful than it should be.  If they just have to add an 
[[optnone]] to their function definition and suddenly get a more 
reasonable debug experience with minimal loss of performance to any of the 
rest of their engine then they are much less likely to have to drop down 
to assembly debugging.  The only reason that we're being such pains in 
pushing so hard on this issue is that we're being pushed so hard 
ourselves.  It's the one bit of feedback that we hear pretty much every 
time we talk to our users and is by far and away our most highly voted-for 
feature request.  Also, I think the fact that other compilers such as MSVC 
already support this in the form of #pragma optimize means that our users 
already have the workflow set up elsewhere and are just looking for us to 
match it.

> 
> For what it's worth I agree with Nick that it should be possible to get 
the
> optnone effect without introducing optnone into LLVM at all, by playing 
games
> with the pass manager.  It does seem like a painful way of doing it 
though.
> 

We're watching the discussion on the new Pass Manager closely in the hope 
that maybe some of what we're after might just come for free there :-).

-Greg



**********************************************************************
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