svn 14566

Rob Landley rob at landley.net
Tue Mar 21 08:33:47 PST 2006


On Tuesday 21 March 2006 3:20 am, Mihai Buha wrote:
> > How does that involve operator associativity rules?  If x==5
> > becomes a
> > statement whose result is discarded, then the statement may
> > be discarded
> > unless it has side effects, which the compiler can trivially
> > tell it doesn't.
>
> There is a difference between "a compiler can tell" and "a
> compiler must tell", or even "a compiler should tell". Your
> statement that "[it] is a bug in the compiler" implies that the
> compiler is required to see whether there are side effects and,
> in case there are none, to optimize the expression.

If we tell it -Os, and it can't handle something that simple, there's really 
no point in trying to micro-optimize any more than that.  For our purposes, 
that is a broken compiler.

> I agree that 
> in the case of an optimizing compiler your statement may be true,

Do you believe compiling busybox on a non-optimizing compiler is relevant?

> I also agree that most of the current compilers may do some sort
> of optimizations,

For a couple decades now, yes.  Compilers under _DOS_ did this.

I took the first half of a graduate course in compiler optimization a couple 
years ago, but unfortunately they skipped this stuff as too simple, too 
obvious, and should already have been covered in any undergraduate class on 
basic compiler development.

Since I didn't have a compiler course as an undergraduate, I had to go get a 
book to read up on it...

> but I don't agree that the code should be 
> written on the assumption that "the compiler would optimize
> this anyway".

Then you write it.

> This is the reason why I prefer ++i instead of  i++.

If you can show me it making a difference on a real compiler currently in use, 
I may start to care.  If said compiler is open source and the patch doesn't 
hurt gcc's output, I'll probably actually apply it.

> respectively, "I will tell him about that issue". Given that,
> I believe you should either silently delete the offending
> text,

Sigh.  Back when Erik was still maintainer I could acquiesce to that sort of 
suggestion by putting the offending text in my spam filter.  Now I'm supposed 
to be mature.  (:P)  So I'll simply say "You are entitled to your beliefs" 
and drop the subject.

> or state in the mailing list rules that "people who 
> work in companies who do that should not send us mail".

"from their brain-damaged work account".

Actually I believe the last time it came up somebody suggested a gmail 
account, and linked to some variant of 
http://en.wikipedia.org/wiki/Alt.fan.warlord

*shrug*

Rob
-- 
Never bet against the cheap plastic solution.


More information about the busybox mailing list