Sorry, I was juggling too many patches out of order.

Note that I made this patch a predecessor for D55345.

Rebase the patch.

I'm all for reusing code, but this is not any sophisticated algorithm, but mere streaming of data. I rather keep the additional methods and simplify the exiting ones to eliminate their special cases for the sake of maintenance. After all, complicating them is what resulted in this issue.

Break up the original patch in 3 installments, one for each existing predicate: AArch64InstrInfo::isScaledAddr(), AArch64InstrInfo::hasShiftedReg(), AArch64InstrInfo::hasExtendedReg().

Question: the code beginning at MCOpcodeSwitchStatement above cannot be used as a regular MCSchedPredicate too. If so, how can I avoid writing the same statement twice, since this condition is used both in AArch64InstrInfo.cpp and in AArch64Sched*.td?

Awesome! Please, stand by.

The issue that I'm trying to avoid is that it's not enough for me to add predicates based on MCSchedPredicate for Exynos processors is other processors don't. Then, if an instruction that I model by using a variant schedule is also modeled by another processor, TableGen will emit no solution at all for the instruction. This patch, which I recognize is just an attempt, aims at allowing the proper solution for a processor using such predicates, while indeed resulting in a clumsy solution the scheduling of the same instruction for other processors.

Exclude test that does not apply anymore.

Isn't this change always enabled for -Os? So it should be easy to test it or to enable down to a single function, shouldn't it?

Rather than a feature in AArch.td, I'd prefer a line in AArch64Subtarget::initializeProperties().

I'm getting mixed results on Exynos, with significant improvements and regressions. I'd like to run more tests, but, at the moment, I'd rather that this feature would be gated, either as @jfb or @rengolin suggested.

In D32564#1259703, @jfb wrote:

Do you have an ETA?

In D32564#1259585, @t.p.northover wrote:

Is that in trunk? I can't see any obvious candidates with a git grep -i exynos. If not, it's probably not relevant to this review.

In D32564#1259155, @jfb wrote:

Do you have specific worries? Or at least a timeline? Seems the patch can be reviewed without waiting for your exploration.

This is good data. However, I'd like to evaluate this patch a bit further on Exynos, if I may.

Can you please provide some figures on the code size saved and the effect on the performance of this change?

Me likes it.