[PATCH] D105413: [ARM] Add lowering of uadd_sat to uq{add|sub}8 and uq{add|sub}16

Daniel Egger via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jul 11 09:36:00 PDT 2021


therealprof added a comment.

In D105413#2869935 <https://reviews.llvm.org/D105413#2869935>, @dmgreen wrote:

> 



> We usually don't treat the dsp instructions as llvm vector operations directly. They don't cover a full enough set of operations to make them worthwhile, and nothing will generate them from llvm/clang.

DSP covers quite a lot of cases but for integer operations only. What makes DSP so interesting is that quite a lot of chips support them, starting from Cortex-M4 microcontrollers up to every CPU manufactured in the last decade or so. It's quite curious that there seems to be little interest in picking up this super low-hanging fruit.

You're right that at the moment I don't know of any compiler generating v4i8 and v2i16 types, but with the current state of code lowering it's quite understandable that noone does since this would result in quite a bit of overhead over scalar code, however if the code generation would be better I could totally see compilers making use of autovectorization and/or exposing SIMD types directly. My focus is very much on MCUs and if LLVM can generate good code for DSP I'd work on the Rust side of code generation.

> For the cases we do recognize, it's from scalar code either through ISel or the ARMParallelDSPPass.

I am aware. ;)

> If you have control of the code, the best bet may be to just use the @llvm.arm.qadd8 intrinsics directly.

Intrinsics are pretty much always a lackluster workaround for me. I want compilers to generate ideal code instead of users having to write it over and over again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105413



More information about the llvm-commits mailing list