[PATCH] D59442: Enable Operand Reordering for Commutative Instructions in the FunctionComparator/MergeFunctions

[Rodrigo Caetano Rocha via Phabricator via llvm-commits]

rcorcs added a comment.

This example that I gave in my comment is a simplistic one that gets canonicalized.
However, this patch would handle more interesting examples as well. Such as the following one:

int foo(int *v, int a, int b, int c) {

  int t1 = (3*a);
  int t2 = (c*b);
  v[0] = t1+t2;
  int t3 = (b*7);
  int t4 = (c*a);
  v[1] = t3+t4;
  return v[0]+v[1];

}

int bar(int *v, int a, int b, int c) {

  int t1 = (a*3);
  int t2 = (b*c);
  v[0] = t2+t1;
  int t3 = (7*b);
  int t4 = (a*c);
  v[1] = t4+t3;
  return v[1]+v[0];

}

which clang with -O1, -O2, or -Os (I haven't tested with other flags) will produce something similar to:

define dso_local i32 @foo(i32* nocapture %v, i32 %a, i32 %b, i32 %c) local_unnamed_addr #0 {
entry:

  %mul = mul nsw i32 %a, 3
  %mul1 = mul nsw i32 %c, %b
  %add = add nsw i32 %mul1, %mul
  store i32 %add, i32* %v, align 4, !tbaa !2
  %mul2 = mul nsw i32 %b, 7
  %mul3 = mul nsw i32 %c, %a
  %add4 = add nsw i32 %mul3, %mul2
  %arrayidx5 = getelementptr inbounds i32, i32* %v, i64 1
  store i32 %add4, i32* %arrayidx5, align 4, !tbaa !2
  %add8 = add nsw i32 %add, %add4
  ret i32 %add8

}

define dso_local i32 @bar(i32* nocapture %v, i32 %a, i32 %b, i32 %c) local_unnamed_addr #0 {
entry:

  %mul = mul nsw i32 %a, 3
  %mul1 = mul nsw i32 %c, %b
  %add = add nsw i32 %mul1, %mul
  store i32 %add, i32* %v, align 4, !tbaa !2
  %mul2 = mul nsw i32 %b, 7
  %mul3 = mul nsw i32 %c, %a
  %add4 = add nsw i32 %mul3, %mul2
  %arrayidx5 = getelementptr inbounds i32, i32* %v, i64 1
  store i32 %add4, i32* %arrayidx5, align 4, !tbaa !2
  %add8 = add nsw i32 %add4, %add
  ret i32 %add8

}

and if you notice the instruction

  %add8 = add nsw i32 %add4, %add

has the operands in the "wrong" order compared to the first function.

This makes the existing -mergefunc fail, but this patch fixes it.

I agree that canonicalization steps help a lot, but, of course, that I like the idea of having a more powerful function merger (as a proponent of one).


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59442/new/

https://reviews.llvm.org/D59442