[LLVMdev] Eliminate Store-Load pair even the LoadInst is volatile

[John Criswell]

Zhou Sheng wrote:
> Hi,
>  
> Thanks, John, I just forgot the multi-thread issue.
Multi-threading is just one example of why volatile exists.  Some 
systems use it for I/O operations (since you don't want the load/store 
to I/O device memory to get optimized away).  Volatile may also be used 
in programs that access shared memory via a shared memory segment (i.e. 
multi-process sharing instead of multi-thread sharing).There may be 
other reasons why volatile is used, but the above are probably the most 
common.

In C, the volatile keyword simply means that the compiler must be 
pessimistic with removing the load/store because memory is affected in 
some way outside the scope of compiler analysis.  I assume LLVM's 
volatile attribute is used to implement these types of optimization 
restrictions.


> I'll write my own pass to handle this as for my project, it is just 
> single-thread case.
As long as you know the transform is safe within the domain of your 
application, it makes sense.  However, my question would be: if you know 
it's safe, then why is the load marked volatile in the first place?  Are 
you sure that volatile is only used for safe shared memory accesses, or 
could it be there for another reason?

-- John T.
>
>
>
> Sheng.
>
>     Date: Thu, 22 May 2008 09:30:45 -0500
>     From: John Criswell <criswell at cs.uiuc.edu
>     <mailto:criswell at cs.uiuc.edu>>
>     Subject: Re: [LLVMdev] Eliminate Store-Load pair even the LoadInst is
>             volatile
>     To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu
>     <mailto:llvmdev at cs.uiuc.edu>>
>     Message-ID: <48358395.3070403 at cs.uiuc.edu
>     <mailto:48358395.3070403 at cs.uiuc.edu>>
>     Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>     Zhou Sheng wrote:
>     > Hi all,
>     >
>     > I put a case into llvm and got the following .ll code:
>     >
>     > ...
>     > %r1419_0_0_0_i376 = alloca i32 ; <i32*> [#uses=2]
>     > ...
>     > %tmp1476_i = lshr i32 %tmp1226_i, 24 ; <i32> [#uses=1]
>     >
>     > store i32 %tmp1476_i, i32* %r1419_0_0_0_i376, align 4
>     > %tmp1505_i = volatile load i32* %r1419_0_0_0_i376, align 4 ;
>     <i32> [#uses=1]
>     >
>     > %tmp1542_i = getelementptr [256 x i8]* @Te, i32 0, i32 %tmp1505_i
>     > ...
>     >
>     >
>     > llvm opt can't remove the redundant store-load pair to just use
>     the value %tmp1476 as the load is volatile.
>     > But I think for the above situation, it's safe to remove
>     store-load, as the allocad  %r1419_0_0_0_i376 just has two users
>     (the one load and one store), correct?
>     >
>     I don't think you can do that.  Loads are often marked volatile
>     because
>     the memory location is accessed in some "undefined" way.  For example,
>     if the pointer to the alloca'ed memory escapes, it could be used for
>     synchronization with another thread.  There could be other, concurrent
>     stores by other threads that will change the value read by the load.
>     Your optimization would break such code because this thread would only
>     see stores that it itself made.
>     > Can I add some code to instcombine or dce for this?
>     >
>     >
>     In general, I think shortcutting the volatile load would be incorrect,
>     and therefore, such a transform should not be a part of
>     instcombine or dce.
>
>     However, if you wanted to, you could write your own custom pass that
>     shortcuts the load *if* you know that in your particular situation
>     that
>     such shortcuts are safe.  For example, if I was writing a
>     front-end for
>     LLVM that naively generated volatile loads for all synchronization
>     variables, I could write a pass that would short-cut the load if it
>     could also prove that the alloca never escapes (and therefore,
>     only the
>     local thread can access the alloca'ed memory).
>
>     -- John T.
>
>
>
>     ------------------------------
>     __________
>
>
>     End of LLVMdev Digest, Vol 47, Issue 102
>     ****************************************
>
>