[PATCH] D148703: [CodeGen] Refactor IR generation functions to use IRBuilder in ComplexDeinterleaving pass

[Igor Kirillov via Phabricator via llvm-commits]

igor.kirillov added inline comments.


================
Comment at: llvm/test/CodeGen/AArch64/complex-deinterleaving-mixed-cases.ll:222-227
 ; CHECK-NEXT:    movi v4.2d, #0000000000000000
-; CHECK-NEXT:    fcmla v3.4s, v1.4s, v0.4s, #0
-; CHECK-NEXT:    fcmla v4.4s, v2.4s, v0.4s, #0
-; CHECK-NEXT:    fcmla v3.4s, v1.4s, v0.4s, #90
-; CHECK-NEXT:    fcmla v4.4s, v2.4s, v0.4s, #90
-; CHECK-NEXT:    fcadd v0.4s, v4.4s, v3.4s, #90
+; CHECK-NEXT:    fcmla v3.4s, v2.4s, v0.4s, #0
+; CHECK-NEXT:    fcmla v4.4s, v1.4s, v0.4s, #0
+; CHECK-NEXT:    fcmla v3.4s, v2.4s, v0.4s, #90
+; CHECK-NEXT:    fcmla v4.4s, v1.4s, v0.4s, #90
+; CHECK-NEXT:    fcadd v0.4s, v3.4s, v4.4s, #90
----------------
NickGuy wrote:
> Any idea what caused these changes? Is it solely down to using a single IRBuilder instance? Or is there some element of non-determinism with regards to the ordering at this point?
While building a new tree consisting of fcmla/fcadd/symmetric from predecessors to successors, it does it without paying attention where the original instructions were. So it caused some irrelevant changes in the order.
It should be deterministic - everything we iterate there uses deterministic structures and maps/sets are only for checking


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148703