<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 18, 2013 at 1:05 PM, Duncan Sands <span dir="ltr"><<a href="mailto:duncan.sands@gmail.com" target="_blank">duncan.sands@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrea,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Attribute optnone was originally intended to be used mainly for debugging<br>
purposes.<br>
Our customers almost exclusively use optimized builds because unoptimize<br>
builds are too slow for their purposes, but the debug experience on<br>
optimized builds is very often not good enough. Applying attribute optnone<br>
to a function would allow the user to debug that function as if it were an<br>
unoptimized build but having the rest of the program fully optimized. With<br>
this use case in mind, I originally decided to make the 'optnone' behavior<br>
similar to -O0.<br>
</blockquote></blockquote>
<br></div>
it sounds like you want GCC's recently added -Og. Sorry to say this, but<br>
optnone sounds like a bad way to solve this problem to me. Personally I<br>
think you should remove optnone and instead work on improving the<br>
interaction between the -O1 optimizers and debug info. Mqybe if optimization<br>
levels become an attribute attached to functions, then we could have a<br>
-Og attribute and teach the optimizers not to do optimizations that unavoidably<br>
play badly with debug info. But for the moment -O1 is the closest thing we have<br>
to -Og.<br></blockquote><div><br></div><div>I haven't looked in depth at -Og, but at least for -O1, it's not really viable to compile these games with -O1. Remember that these games push up hard against a frame time limit, so in general anything that globally decreases performance will cause frames to be missed. Anecdotally from my work this Summer, compiling with -O1 (vs the usual of -O2/-O3) results in the game essentially becoming unplayable (and with -O0 globally it's even worse: the game doesn't just run slow, it' doesn't run *at all* (it can't meet deadlines necessary to even put an image on the screen!)).</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For what it's worth I agree with Nick that it should be possible to get the<br>
optnone effect without introducing optnone into LLVM at all, by playing games<br>
with the pass manager. It does seem like a painful way of doing it though.<br>
<br>
Ciao, Duncan.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thank you! Finally I understand the motivation behind "optnone" well enough to<br>
make informed decisions about its design!<br>
<br>
Firstly, the real way to fix this is to solve the optimized+debugging<br>
experience, but of course that's not happening any time soon enough. You need<br>
something now, but it does point out that maybe optnone isn't something we want<br>
to have in llvm forever -- it's just a workaround for a worse problem.<br>
<br>
I think you can build this out of existing pieces, or optionally with a couple<br>
of extensions. The frontend needs an 'optnone' attribute. When codegen'ing such<br>
a function, it should apply the 'noinline' attribute to it, and also to each of<br>
the call or invoke instructions that it contains.<br>
<br>
In LLVM, you need to control two pieces. Your frontend already controls the pass<br>
manager, at least to the extent that its API will permit. If you don't want to<br>
run module passes or CGSCC passes, you can just iterate over the list of<br>
functions and skip the functions you don't want to optimize and just run over<br>
the other ones. Or you could make a small extension to add a "skipFunctionList"<br>
to the pass manager, but really you can make that yourself: remove the<br>
function's body from the function before running the pass manager. Yep. Splicing<br>
a functions's blocks into a parentless function will leave a declaration in<br>
place in the module at the same pointer address. Then you put it back after<br>
you've run the IR-level pass managers. It's even an O(1) operation.<br>
<br>
Finally, you also need to ensure that the backend emits at -O0. The<br>
TargetMachine stores some options (TargetOptions) on a per-function basis. Make<br>
the codegen opt level one of those. (This may be somewhat difficult, you could<br>
run everything through the -O0 codegen when anything is 'optnone' -- but then,<br>
your existing 'optnone' attribute is in the exact same situation.)<br>
<br>
Nick<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
About the DAE:<br>
I agree that the DAE would end up removing unused arguments only in<br>
trivial cases.<br>
This may still be acceptable from a debugging perspective since it<br>
wouldn't really negatively affect the user debugging experience (i.e. the<br>
user simply will not be able to "see" dead argument).<br>
However, if the plan is to achieve a behavior similar to -O0, then it may<br>
still be better to not allow DAE to change optnone functions.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ This attribute cannot be used together with the<br>
</blockquote></blockquote></blockquote></blockquote>
``alwaysinline``<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ attribute; this attribute is also incompatible<br>
+ with the ``minsize`` attribute and the ``optsize`` attribute.<br>
+<br>
+ The inliner should never inline this function in any situation.<br>
+ Only functions with the ``alwaysinline`` attribute are valid<br>
+ candidates for inlining inside the body of this function.<br>
</blockquote>
<br>
Ha, "alwaysinline" strikes again! What happens when the unmovable<br>
"optnone" meets the irrestistable "alwaysinline"? Maybe the compiler<br>
should just error out in this case: declare that this combination is<br>
invalid and have the verifier catch it.<br>
</blockquote>
<br>
Yes, those attributes are incompatible and r189101 introduces rules in<br>
</blockquote></blockquote>
the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Verifier to catch when attribute 'alwaysinline' is specified when<br>
'optnone' is also present.<br>
If for example I define a function with both attributes optnone and<br>
alwaysinline, then the verifier will be able to catch it and print out<br>
that "Attributes 'alwaysinline and optnone' are incompatible!".<br>
</blockquote>
<br>
I meant: what if the optnone function calls a function marked<br>
</blockquote>
alwaysinline.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Inlining it into the optnone function changes the code of the optnone<br>
function, so is contrary to the principal that optnone function bodies<br>
</blockquote>
are<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
just left alone.<br>
</blockquote>
<br>
The idea is trying to get 'optnone' as close as possible to the -O0<br>
behavior.<br>
This is the main reason why I originally decided to allow the inlining of<br>
alwaysinline<br>
functions inside optnone functions.<br>
<br>
I think the documentation should be improved to emphasize that -O0<br>
behavior.<br>
<br>
Andrea<br>
<br>
******************************<u></u>******************************<u></u>**********<br>
This email and any files transmitted with it are confidential and intended<br>
solely for the use of the individual or entity to whom they are addressed.<br>
If you have received this email in error please notify <a href="mailto:postmaster@scee.net" target="_blank">postmaster@scee.net</a><br>
This footnote also confirms that this email message has been checked for<br>
all known viruses.<br>
Sony Computer Entertainment Europe Limited<br>
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United<br>
Kingdom<br>
Registered in England: 3277793<br>
******************************<u></u>******************************<u></u>**********<br>
<br>
P Please consider the environment before printing this e-mail<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>