[LLVMdev] LLVMdev Digest, Vol 76, Issue 44

[Kenneth Boyd]

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