Since we are in the area, what *should* O1 do?
It's basically good for nothing, since it doesn't tune for size or
performance. The only good I personally ever have for it is once in a
while there is a miscompile at -O1 which narrows the problem.
Would it be crazy to make -O1 equivalent to -Os?
- Daniel
I've always used O1 for a quick cleanup so that my debug code doesn't completely suck, but hasn't been optimized into oblivion for gdb. Also makes looking at the resultant assembly dumps fairly easy.
But yes, that'd be crazy 
-eric
Daniel Dunbar <daniel@zuster.org> writes:
Since we are in the area, what *should* O1 do?
"Try to produce fast code but do not apply transformations that makes
debugging hard"
That works for me!
My father prefers that to writing assembly code directly. Seems like a
pretty normal thing to do...
Crazy is producing assembly directly, which he still does most of the time... 
cheers,
--renato
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm
Since we are in the area, what *should* O1 do?
It's basically good for nothing, since it doesn't tune for size or
performance. The only good I personally ever have for it is once in a
while there is a miscompile at -O1 which narrows the problem.Would it be crazy to make -O1 equivalent to -Os?
I've always used O1 for a quick cleanup so that my debug code doesn't
completely suck, but hasn't been optimized into oblivion for gdb. Also
makes looking at the resultant assembly dumps fairly easy.
If this is from the compiler programmer perspective, we have better
tools for that. If this is from the user perspective, currently they
all are bad with LLVM for the former, and we should similarly fix all
of them.
But yes, that'd be crazy
Was that a -1 on doing it, though?
- Daniel
It would be interesting to see if LLVM has improved since 2.5 on this
benchmark, could you try the prerelease here?
http://llvm.org/prereleases/2.6/
A 40% performance loss is bad, something should be done about it for
LLVM 2.7 (if it is too late for 2.6 already).
Best regards,
--Edwin
I've always used O1 for a quick cleanup so that my debug code doesn't
completely suck, but hasn't been optimized into oblivion for gdb. Also
makes looking at the resultant assembly dumps fairly easy.If this is from the compiler programmer perspective, we have better
tools for that. If this is from the user perspective, currently they
all are bad with LLVM for the former, and we should similarly fix all
of them.
Well, it's mostly for both
But yes, that'd be crazy
Was that a -1 on doing it, though?
Don't see much of a reason to be incompatible with gcc on this one. Maybe a new set of command line options for optimization? But what do I know?
*shrug* I've always hated dealing with command line options
-eric
I've always used O1 for a quick cleanup so that my debug code doesn't
completely suck, but hasn't been optimized into oblivion for gdb. Also
makes looking at the resultant assembly dumps fairly easy.If this is from the compiler programmer perspective, we have better
tools for that. If this is from the user perspective, currently they
all are bad with LLVM for the former, and we should similarly fix all
of them.Well, it's mostly for both
But yes, that'd be crazy
Was that a -1 on doing it, though?
Don't see much of a reason to be incompatible with gcc on this one.
Note that this comment doesn't really make sense. The set of
optimizations which runs for -O1 and -Os aren't at all "gcc
compatible", changing the list of what runs at -O1 doesn't make
llvm-gcc/clang any more or less "compatible". Given that we are free
to change the passes that run at -O1, I'm just suggesting we change it
enough that it coincides with -Os.
- Daniel
Don't see much of a reason to be incompatible with gcc on this one.
Note that this comment doesn't really make sense. The set of
optimizations which runs for -O1 and -Os aren't at all "gcc
compatible", changing the list of what runs at -O1 doesn't make
llvm-gcc/clang any more or less "compatible". Given that we are free
to change the passes that run at -O1, I'm just suggesting we change it
enough that it coincides with -Os.
Ha. It's a philosophical change. I'd still say that our O1 mostly matches with the idea of "compiling for speed without taking too much time" instead of "compiling for size".
That said, I'm not really against the idea in general, just that an incompatibility would be confusing for those accustomed to the other way. Why I thought that a new set of options would probably be best for this sort of thing.
-eric
Daniel Dunbar <daniel@zuster.org> writes:
[snip]
Given that we are free
to change the passes that run at -O1, I'm just suggesting we change it
enough that it coincides with -Os.
Why throw away one option making it a synonym for something else? If the
user wants -Os he already has it.
-O1 is interesting for "fast debuggable code" or, as Eric says, "fast
code, quickly made."