LLVMdev Digest, Vol 76, Issue 44

Project Infrastructure LLVM Dev List Archives
1

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.

2

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