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

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. 
For another case, see sqrt.

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?

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

Hi Kenneth,
> 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.]
both dragonegg and llvm-gcc remove the volatile.  I don't see why they
shouldn't, since the program behaves exactly the same (as far as anyone
external can tell) as if it had been left there.

Ciao,

Duncan.