[llvm-commits] [PATCH (try 4)] Add an atomic lowering pass

[Peter Collingbourne]

Ping...

On Sun, Jul 11, 2010 at 04:52:11PM +0100, Peter Collingbourne wrote:
> Hi,
> 
> Ping...
> 
> I also updated the patch (attached) to add an entry in docs/Passes.html
> for the pass.
> 
> Thanks,
> 
> On Wed, Jun 30, 2010 at 02:42:11PM +0100, Peter Collingbourne wrote:
> > Hi,
> > 
> > Here is the new version of the patch.  I updated it to use
> > getArgOperand and fixed a coding style issue (header ordering).
> > 
> > Thanks,
> > 
> > On Thu, Jun 24, 2010 at 12:32:42AM +0100, Peter Collingbourne wrote:
> > > Hi Duncan,
> > > 
> > > On Wed, Jun 23, 2010 at 09:25:39AM +0200, Duncan Sands wrote:
> > > > Hi Peter,
> > > > 
> > > > > My main motivation for the single-thread lowering is to be able to run
> > > > > code that uses these intrinsics in the KLEE symbolic execution engine
> > > > > but I imagine it could have other uses such as a whole-program LTO
> > > > > that lowers atomic operations to more efficient non-atomic operations
> > > > > when it is known to be safe to do so.
> > > > 
> > > > instead, how about writing an LLVM IR pass that turns atomic intrinsics into
> > > > non-atomic equivalent LLVM IR?
> > > 
> > > Yes, that seems more sensible.  I refactored the lowering into a pass
> > > and added the remaining intrinsics (see attached patch).  I'll commit
> > > this if approved.
> > > 
> > > I wonder if IntrinsicLowering should also be made into a pass, for
> > > consistency with the other lowering passes.
> > > 
> > > > Finally, I guess even "single threaded" code
> > > > may have a use for some atomic operations if it makes use of signal handlers.
> > > 
> > > Yes, good point.  Perhaps "non-preemptible" is better terminology
> > > which is what I used in the new patch.
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lower-atomic3.patch
Type: text/x-diff
Size: 11084 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100803/f06e8e51/attachment.patch>