[llvm] [AArch64] Disable Xor merging for certain neoverse cores (PR #165393)

[David Green via llvm-commits]

davemgreen wrote:

> No not really. This was done as we saw value in keeping the eor separate for cores with V0 vector pipeline bandwidth . I agree with you that the benefit is situational and really depends on the surrounding code, but we thought it would be better default to keep it separate, as the throughput hit in case V0 is full would be higher than 1 extra latency cycle. In any case, this is my first time doing this kind of work and I am not sure what is the best to implement this kind of cpu tuning, so I would appreciate advice on how to best do this. Would I need to write some kind of pass which will analyze surrounding code to make this decision ?

Hi - When this was added back in https://reviews.llvm.org/D108793 we would have ran some (quick) benchmarks on likely either the Neoverse V1 or the Neoverse V2 along with some models, and were not unhappy with the results. Which either means that it was fine for the test cases we ran, or it didn't come up in many cases. Now that it has been in-tree a while the onus is probably on proving it shouldn't be used, and like you say it will be situational. The eor3 should only be a problem in loops that a limited by V0 throughput, which means in many loops it should be fine as they will be limited by something else.

We don't really have an optimization yet that tries to look at an entire block and figure out which is better between one instruction and another. I don't think we have needed it up to this point. The closest I can think of is MachineCombiner, which looks at trees for critical depth, or the MachineScheduler which only performs scheduling at the moment. They both use the information in the scheduling model, which this new optimization could reuse. We would need to make sure if was worth it for compile-time and that it improved some cases enough.

https://github.com/llvm/llvm-project/pull/165393