[PATCH/RFC] Lowering atomic accesses in SystemZISelLowering

Richard Sandiford rsandifo at linux.vnet.ibm.com
Fri May 31 09:02:17 PDT 2013


One feature of the z architecture is that almost all aligned loads
and stores are atomic (or "block concurrent as observed by other CPUs",
as the manual calls it).  Out of the instructions we currently support,
LRV(G) and STRV(G) are the only exceptions I know of.  Those instructions
are also the only ones for which we forbid volatile accesses.

So if we have an atomic load followed by an add, we should be able
to use the "add reg,mem" instruction (A or AG).  This is so pervasive
that it seems easier to lower atomic loads and stores before final
instruction selection.  The lowered load or store could have the
same MachineMemOperand and chain operands as the original.  (Atomic
operations are currently volatile as far as the MachineMemOperand is
concerned, so the LRV(G) and STRV(G) exclusions even come "for free".
I'd still be happy with an approach that required changes to
SystemZOperators.td:Nonvolatile{Load,Store} though.)

The attached proof-of-concept patch does this.  It just includes
the main patch and one testcase.  The plan is to extend existing
tests too (I've done some of that locally just to check).

The question is: is it safe to lower in this way?  Even if it's safe now,
is it likely to interfere with future plans?  One reason for asking is that,
AIUI, the loads in:

define i32 @foo(i32 *%ptr0) {
  %ptr1 = getelementptr i32 *%ptr0, i64 1
  %ptr2 = getelementptr i32 *%ptr0, i64 2
  %ptr3 = getelementptr i32 *%ptr0, i64 3
  %val0 = load atomic i32 *%ptr0 monotonic, align 4
  %val1 = load atomic i32 *%ptr1 monotonic, align 4
  %val2 = load atomic i32 *%ptr2 monotonic, align 4
  %val3 = load atomic i32 *%ptr3 monotonic, align 4
  %sub = sub i32 %val3, %val0
  %or = or i32 %sub, %val2
  %and = and i32 %or, %val1
  ret i32 %and
}

could be reordered to allow:

  l ..., 12(%r2) // Load
  s ..., 0(%r2)  // Subtract
  o ..., 8(%r2)  // OR
  n ..., 4(%r2)  // AND

but this currently isn't done.  The reordering does happen for
nonatomic loads.

Thanks,
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lower-atomics.diff
Type: text/x-patch
Size: 10146 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130531/a6356a55/attachment.bin>


More information about the llvm-commits mailing list