[PATCH] D38196: [AArch64] Avoid interleaved SIMD store instructions for Exynos

[Abderrazek Zaafrani via Phabricator via llvm-commits]

az added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64VectorByElementOpt.cpp:333-353
+      return false;
+    ReplInstrMCID.clear();
+    OriginalMCID = &TII->get(AArch64::ST4Fourv16b);
+    for (unsigned i=0; i<4; i++) {
+      ReplInstrMCID.push_back(&TII->get(AArch64::ZIP1v16i8));
+      ReplInstrMCID.push_back(&TII->get(AArch64::ZIP2v16i8));
+    }
----------------
kristof.beyls wrote:
> az wrote:
> > kristof.beyls wrote:
> > > From a logical point of view, this is a lot of code that repeats information encoded in a different way in the big switch statements in optimizeLdStInterleave.
> > > It'll be easy to update one location in the future and forget the other location.
> > > Couldn't the logic in the switch statements in optimizeLdStInterleave be reused here somehow, so that the information is only encoded once?
> > Good suggestion to simplify that code. There are several ways to improve it and here is one way: store the re-writing rules in a table member variable of the class and use that table in shouldExitEarly and in optimizeLdStInterleave. Note that I have not changed optimizeLdStInterleave yet (only used new table in shouldExitEarly). I would like to make sure that what I did is the kind of changes you had originally in mind and if so, then I will use it in optimizeLdStInterleave.
> > 
> Yes, this is the kind of change I had in mind.
> I didn't try to figure out if everything could be driven from such a table, but what you wrote in shouldExitEarly is roughly what I had in mind (with a follow-on nit-pick about making the code even more data-driven in my other comment on the new code).
Thank you for the feedback. I will work on the table approach in a day or two. In the meantime,  I will refer you to this abandoned patch https://reviews.llvm.org/D27738 where I tried to add a table driven approach to the original pass. It was seen as adding complexity. The tables in this review are for different purpose and I think that we should go with it but I just want to let you about the old attempt.     


https://reviews.llvm.org/D38196