[LLVMdev] LLVMdev Digest, Vol 76, Issue 43

[Kenneth Boyd]

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 5.1.2.3/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

int main()
{
    volatile int i = 1;
    return 0;
}

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.]

Kenneth