[LLVMdev] Prevent instruction elimination

[John Criswell]

On 10/25/10 10:56 AM, Kenneth Uildriks wrote:
> On Mon, Oct 25, 2010 at 10:52 AM, John Criswell<criswell at illinois.edu>  wrote:
>> On 10/25/10 10:43 AM, Duncan Sands wrote:
>>> Hi John,
>>>
>>>> As for instructions, I don't know of an instruction which does nothing,
>>>> won't be removed by optimization, and yet does not inhibit
>>>> optimization.  Perhaps a local alloca and a volatile load or store would
>>>> do the trick?  Being volatile, the compiler won't remove it (or if it
>>>> does, it's a bug, and you should file a bug report), and since it loads
>>>> from a memory object not used for anything else, alias analysis should
>>>> be able to see that it doesn't interefere with any other load/store.
>>> LLVM certainly will remove volatile loads and stores to local variables
>>> (at least in simple situations).  I suggest using an empty asm statement.
>> Really?  Isn't that illegal?  The whole point of "volatile" is to tell
>> the compiler that it should not remove a load/store.  Optimizing them
>> away seems counter-intuitive and directly contradicts the documented
>> behavior in the LLVM Language Reference manual (which states that the
>> number of volatile loads/stores will not be changed).
> If a local variable doesn't escape the function, no other thread can
> touch it, and a volatile load from it is thus proven equivalent to a
> regular load.

The above logic makes sense when you're talking about non-volatile loads 
and stores.  To me, it doesn't make sense for volatile loads and stores.

The whole point of volatile is to tell the compiler that its assumptions 
about how memory works doesn't apply to this load or store and it 
should, therefore, leave it alone and not do any optimization.  
Informally, it's the programmer's way of telling the compiler, "I know 
what I'm doing and you don't, so don't touch that memory operation."

What you and Duncan are saying is that volatile is volatile except when 
it isn't.  I think that's poor design.  At the very least, it is 
confusing, and at worst, it prevents LLVM from handling C's "volatile" 
keyword correctly.

If it's decided that the current behavior is what LLVM will do, it 
should at least be documented in the LLVM Language Reference Manual.  
Right now, the current behavior directly contradicts the reference 
manual, and that is definitely confusing.

-- John T.

>
>> -- John T.
>>
>>> Ciao,
>>>
>>> Duncan.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>