[LLVMdev] LLVMdev Digest, Vol 76, Issue 43
zaimoni at zaimoni.com
Mon Oct 25 20:00:27 CDT 2010
On 10/25/2010 7:33 PM, Dale Johannesen wrote:
> On Oct 25, 2010, at 5:13 PMPDT, Kenneth Boyd wrote:
>> On 10/25/2010 6:31 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.
>> I'm not going to bother quoting C99 220.127.116.11/2,3 verbatim, as we already
>> have Word of God (Duncan Sands) that the C99 (and C90) standard's
>> requirements on volatile are intentionally being violated.
> There is no inherent reason llvm "volatile" has to have to the same semantics as C "volatile" just because they're spelled the same.
Right, the thread strictly is about LLVM IR rather than C or C++.
What I don't see (given what Duncan Sands mentioned), is how LLVM's
optimizers *can* be trusted to preserve C or C++ volatile semantics.
> That said, I'm strongly on the side of those who think removing volatile loads is a bad idea. But the last time this came up, I wasn't able to construct a case where this resulted in externally visible incorrect behavior. Can anyone?
Well...strictly as LLVM IR I find externally visible incorrect behavior
unlikely, it's just a "different definition". For C and C++, I'd be
looking at more complicated variations of
volatile int i = 1;
It's clear that the LLVM IR representation of i cannot be simply
IR-volatile qualified, as that load gets optimized out while C and C++
won't optimize it out. I'd *hope* that DragonEgg and llvm-gcc both
leave the load of i in, when in --pedantic mode. [That is, I expect it
to take something more intricate than this elementary test case to
trigger any bugs here.]
More information about the LLVMdev