On May 25, 2011, at 1:09 AM, Renato Golin wrote: > On 25 May 2011 04:20, Bruno Cardoso Lopes <[email protected]> wrote: >> I see no reason for it go in another separated patch, because it's a >> requirement, if it's not in pairs, the instruction is wrong. > (...) >> I lower both of them, the former using tablegen, the later in iseldag. >> I have no plans to add the others, the only reason I'm trying to add >> this one is because there's no way to represent the pair restriction >> using inline asm. > > Ok, just checking. ;) > > >> Because of that, I still think that would be good to have a "ldrexd" >> and "strexd" around. But I'm open to any better approach, if there's >> one available. > > Yes, I know. My idea was to use @llvm.atomic.load.i64 (rather than > load.add.i64) to map to the same concept. > > I don't know if other architectures have the atomic load/store > instructions, but if they do, it makes sense to be generic.
PPC does. This gets ugly for ARM because i64 isn't a legal type, but we have these 64-bit instructions. So it's hard to match them effectively. For additional builtins that map directly to ldrex/strex, which I'm given to understand ARM's compiler supports, we would indeed need new intrinsics (one for each data size). We also want to use these instructions for the 64-bit versions of the __sync* builtins. Those currently generate a libcall, but they don't really need to. -Jim _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
