Am 03.11.2011, 17:21 Uhr, schrieb kenji hara <[email protected]>:

2011/11/4 Nick Sabalausky <[email protected]>:
"kenji hara" <[email protected]> wrote in message
news:[email protected]...
2011/11/3 Nick Sabalausky <[email protected]>:
I don't know much about the internals of DMD, but would this make any
sense?:

When unrolling code, keep track of where the unrolled parts came from.
Only
issue an unreachable code warning if *all* the unrolled versions of the
original line X are unreachable.

First, when we use -w option, we usually want to show *all* warnings of
codes.
Isn't it your expects?


All real warnings, yes, but this one is just simply incorrect. The line *in the source code* that says "writeln( "A: ", member );" *does*, in fact, get reached. Just because it doesn't get reached in *every* iteration doesn't
change that fact that it *does* get reached and is therefore *not*
unreachable code. The fact that the compiler unrolls it behind-the-scenes is irrelevent to the user - that merely explains why the warning is *currently*
thrown, not why it *should* be thrown.

Second, each unrolled loop bodies is separately analyzable by the
compiler.
There is no reason to drop the detectable information, unless other
factors affect (such as performance).

I don't know why you want to reduce warnings that (probably) you expects.


I don't see why anyone would ever expect this warning at all. *All* lines inside the user's foreach body *do* get used. It's the *compiler's* internal
processing that *adds* in some dead code behind-the-scenes. The source
doesn't have any dead code. It's just like inlining:

int foo(int x)
{
   if(x > 5)
       return 5;
   return 1;
}

void main()
{
   int x;
   x = foo(22);
}


Inlining could turn that into:

void main()
{
   int x;
   if(22 > 5)
       x = 5;
   else
       x = 1;
}

Now you have dead code: "x = 1;". But nobody would ever expect to get an
"unreachable code" warning from that. It would never even be helpful. It
would always just be noise. Same goes for the OP's foreach example.

In both this inlining example and the OP's example, what's important is
whether any of the *user's* code is unreachable, not whether any of the
compiler's internally-generated code is unreachable.

OK. You want to detect unreachable codes that *human feels* with -w.
I want to detect codes that is *computed* as unreachable.

I think that the -w option's Raison d'etre is to detect all of the
*potentially* unreachable codes.
For the purpose, -w should detect many codes as far as possible.
There is no reason to reduce information by merging unrolled loops.

The fact that the compiler unrolls it behind-the-scenes is
irrelevent to the user

No, foreach with tuple always unrolled. It is basically truth in
strict-typed language.
Because each elements can have different types.

And with an unrolled loop, its body code does *small generative
programming*, and the generated codes may have unreachable statements.
Current -w is useful tool to terminate them.

Finally from compiler developer sight:
Current dmd uses same statically analyzer against unrolled and normal
loops. It has been the compiler implementation simple.

Kenji Hara

I don't understand why you want it to behave like this. Like Nick, I think the loop-unrolling or inlining should be transparent and not issue warnings that aren't understandable from the code at hand. And second the compiler should be free to remedy the situation itself by removing the dead code it just generated :p God damn, isn't that just obvious?

Reply via email to