llvm dev - Oct 2010 - [LLVMdev] LLVMdev Digest, Vol 76, Issue 44

>>
>> Your objection is like saying that it isn't kosher to ignore the
>> "register" keyword, because
>> "I know what I am doing and you don't.....".
> What isn't kosher, is making side effects disappear from a C program.
>
> Kenneth
>
Ken,
          to have a valid complaint you have to demonstrate a program  
that
behaves incorrectly when compiled with LLVM, so far you have not, you
have only objected to the way it optimizes.  You have not demonstrated
a "side effect" that matters, and LLVM specifically looks for ones  
that do
matter and preserves them and is free to remove ones that don't matter.

are you going to also complain if "register volatile" variables get  
treated
similarly, I don't think so, because we both know that something in a
general purpose register can't possibly be a memory-mapped IO device
interface with side effects.  LLVM is simply extending that logic to
local stack frame variables.

Peter Lawrence.

On 10/26/2010 4:05 PM, Peter Lawrence wrote:On 10/26/2010 4:05 PM, Peter 
Lawrence wrote:
>>> Your objection is like saying that it isn't kosher to ignore
the
>>> "register" keyword, because
>>> "I know what I am doing and you don't.....".
>> What isn't kosher, is making side effects disappear from a C
program.
>>
>> Kenneth
> Ken,
>            to have a valid complaint you have to demonstrate a program
> that
> behaves incorrectly when compiled with LLVM,
Else-thread, Duncan Sands has confirmed that sufficiently earlier 
versions *did* violate C90/C99, but ToT appears to be volatile-correct 
for the slightly over-complicated true program (as might be expected 
from John Regehr's work).
> ....
> are you going to also complain if "register volatile" variables
get
> treated
> similarly,
Yes.  Intentional violations of the C and C++ standards by CLang, 
DragonEgg, and llvm-gcc should be explicitly documented, period.  AFAIK 
these have not been (confirmation by a lead developer on mailing-list is 
pretty obscure, this should be in the main documentation).  Pointers to 
refuting documentation in releases welcome.
>   ..., because we both know that something in a
> general purpose register can't possibly be a memory-mapped IO device
> interface with side effects.
Which doesn't mean anything to a full-blown
emulation.
>    LLVM is simply extending that logic to
> local stack frame variables.
As a matter of LLVM IR, no problem.  With total control of the virtual 
machine, this optimization is reasonable.  (It just means that  a 
volatile C local stack frame variable cannot be represented accurately, 
as a volatile LLVM IR local stack frame variable.)

As a matter of C, or C++ : this is fine *if* it is explicitly 
documented, as an intentional exception to language standard 
conformance.  I view this to be a documentation bug in affected 
releases, not a compiler bug.

Kenneth