[PATCH] D152827: [AArch64] Correctly determine if {ADD,SUB}{W,X}rs instructions are cheap

[Dave Green via Phabricator via llvm-commits]

dmgreen added a comment.

In D152827#4476856 <https://reviews.llvm.org/D152827#4476856>, @chill wrote:

> In D152827#4434233 <https://reviews.llvm.org/D152827#4434233>, @dmgreen wrote:
>
>> Adding handling for ADDWrs with LSLFast sounds good to me. I'm not so sure about this CustomCheapAsMoveHandling though. Ignoring the fact that isCheapAsMove is a bit of a strange concept nowadays, it seems to be missing some of the instructions usually marked as isAsCheapAsAMove (things like COPY and IMPLICIT_DEF, as well as target nodes like FMOV's and MOVI's). I would also like it if either all cpus used hasCustomCheapAsMoveHandling (especially for the testing) or if they were at least closer in terms of functionality.
>
> TBH, I greatly dislike how `AArch64InstrInfo::isAsCheapAsAMove` looks right now.
>
> It seems quite more nicer and streamlined if it was organised like:
>
>   if (Exynos things) {
>     return doExynosThings();
>   }
>   
>   switch (Opcode) {
>     default: return  MI.isAsCheapAsMove(); // fallback to the default instead of `false`
>   
>   // Opcode specific processing, look at target features
>    case Opc1:
>   ...
>     case Opc1:
>   ...
>   }
>
> It'll handle `COPY` and `IMPLICT_DEF` and no need for `FeatureCustomCheapAsMoveHandling`.

Yeah that sounds like a good idea. We can be more precise and have less unnecessary alternative code paths. I'll take a look.

>> Do we think that isAsCheapAsAMove should be all instructions that are really as cheap as a mov? (As in, zero latency move instructions, handled in rename). Or should it be all instructions that are single cycle, like ADDs and ORRs, etc?
>
> What I can tell from looking at the source, it's used as a heuristic, guiding re-materialisation (?), so it's usually in the context of shortening/not-extending live ranges
> and trying to avoid spills, in that sense  one-cycle ADD could be more expensive on paper that a zero-latency MOV, but in practice I'm not sure MOV's advantage
> materialises that often.

That sounds OK to me. We can treat it as cheap instructions that are roughly cost=1, and hopefully the benchmarks will agree.

BTW, we found recently that LSLFast may want to be split into two different features. One for whether the add with shift will be cheap and another for the addressing modes. That shouldn't alter much here though, it just might be split out in the future.


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

https://reviews.llvm.org/D152827