Re: Linux kernel, possible useless continue

Ulrich Eckhardt <doomster@xxxxxxxx> writes:
Rainer Weikusat wrote:
Ulrich Eckhardt <doomster@xxxxxxxx> writes:


for(..; .. && !x; ..)

The only difference is the initialisation statement in the inner
loop, and for the case we're talking about this small difference
doesn't make a difference overall, in particular not when it is
compiled with a halfway-decent optimiser.

As I understood the original question, it was about code semantics and
not about hypothetical, accidental properties of unknown machine code
generated by a random compiler for an arbitrary architecture.

The compiler that is able to digest Linux is not so random ... ;)

It is at least a range of gcc releases.

Seriously, fact remains that the initialisation is low-cost in any

This depends on the generated machine code (eg does it initialize a
register or a memory location) and on the definition of 'low-cost'.

Also, it might even be weighed up by the removal of the check
for the continue and less instruction-cache use,

This depends on the generated return code as well.

but neither is important enough to merit any obfuscations in code

To me, the code is 'more obfuscated' if it contains more semantically
useless things, which I have to understand to understand that they are
semantically useless.


What remains fact is that the if-clause with the continue can be removed
without changing the behaviour of the code,

This may or may not be so, and depends on the generated machine code
as well.

And wasn't "established theory" that one should rather not code to
the idiosynkrasies of some translation or execution environment, but
instead try to express the intent of the code clearly and leave 'the
gory details' exactly to the compiler?

I'm not sure what you are implying with this.

I am not implying anything. What you advocate would be a
compiler version and translation algorithm dependant hack. That the
hack is not intended to improve the generated code, only believed to
not make it worse doesn't make it less of one. This is the stuff one
may include in code if there is evidence that it actually improves
something relevant, and even then, it should better be avoided.