On Tue, 17 Jun 2014 09:29:42 -0600, Jonathan Roelofs wrote: > > > On 6/17/14, 2:11 AM, Renato Golin wrote: > > On 16 June 2014 23:59, Jonathan Roelofs <[email protected]> > > wrote: > >> if ( windows ) return true; > >> else if ( arch >= v6 ) { > >> version = whatever; > >> } else if ( !linux && !freebsd && !netbsd && !bitrig ) { > >> return false; > >> } > >> > >> if ( Profile == "M" && MaxAtomicInlineWidth) { > >> MaxAtomicPromoteWidth = 32; > >> MaxAtomicInlineWidth = 32; > >> } > >> return true; > > > > This sequence sounds correct to me, too. > After having slept on this, I don't think I was correct with that > snippet, and here is why: > > In order for the atomic inlining to be safe here, we must satisfy > two conditions: > 1) The architecture supports ldrex/strex > 2) The platform provided builtins (read: libgcc), if any > (read: baremetal), implements them using the same primitives > (i.e. not a swp-based kernel-provided cmpxchg, or otherwise) > > In the case of baremetal, we really only care about #1. But when > there is a platform involved, we have to be more careful that we > do using the same primitives that the libcalls are implemented > with, being conservative when we don't know that it is safe... That > means emitting libcalls both when we know we have to, and when > we're not sure. > > The original code before Phoebe's patch almost gets that right, but > is a little too conservative in the baremetal cases on both M-class > cpus and non M-class cpus. > > Attached is what I now think the patch ought to be.
That works fine as well. I'm all for your changed version. > Cheers, > Jon > > P.S. Phoebe, sorry for adding to the confusion :) > > > > cheers, > > -renato > > > > -- > Jon Roelofs > [email protected] > CodeSourcery / Mentor Embedded _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
