[LLVMdev] bug or expected behaviour?

[Joshua Cranmer 🐧]

On 6/4/2013 7:31 PM, David Mirabito wrote:
> Hi Carl,
>
> I don't know much about the specifics of any given optimisation, but if you do something like the following, you can at least see which optimisation pass is responsible.
> At the very least perhaps that can point to the next place to investigate. (also interesting to note Apple's shipped clang doesn't exhibit this behaviour, I had to use my own recent svn tree)
>
> $ clang -arch arm -emit-llvm  -S -O0 example.c -o arm.bc
> $ opt -print-after-all -O1 arm.bc
>
> I can see where the branch test is whittled down to an 'if true' and then eliminated, but cannot comment as to why this might be.
>
 From reading C11, I can posit a potential spec explanation:

Start with x--. Per C11:
If both the pointer operand and the result point to elements of the same 
array object, or one past the last element of the array object, the 
evaluation shall not produce an overflow; otherwise, the behavior is 
undefined.

The optimizer can therefore conclude that if this program has 
well-defined behavior, then x can never point to the null pointer 
constant (since the null pointer constant is not part of any array 
object). As a result, the "if (!x)" branch would never trigger, and is 
dead code.

So this doesn't look like an invalid optimization per C11, but that 
doesn't mean that it's necessarily desired behavior in the optimizer.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist