This follow the lead of https://reviews.llvm.org/D68974 to add lowering
of unsigned saturated addition/subtraction.
Signed-off-by: Daniel Egger <daniel@eggers-club.de>
Paths
| Differential D105413
[ARM] Add lowering of uadd_sat to uq{add|sub}8 and uq{add|sub}16 ClosedPublic Authored by therealprof on Jul 4 2021, 4:47 PM.
Details Summary This follow the lead of https://reviews.llvm.org/D68974 to add lowering Signed-off-by: Daniel Egger <daniel@eggers-club.de>
Diff Detail
Unit TestsFailed
Event TimelineHerald added subscribers: danielkiss, hiraditya, kristof.beyls. ยท View Herald TranscriptJul 4 2021, 4:47 PM Comment Actions Hello. Looks like a good patch to me.
Comment Actions
The opcode selection would be vastly more complex but I can certainly take on a rework of that function if desirable. Comment Actions
Yeah, it sounds like it should share more code than it complicates finding the new opcode. Comment Actions
Sorry I don't follow. Are you asking me to unify the functions or saying it's fine as is? ๐ Comment Actions
Yep, unifying them sounds better to me. It looks like its should be possible to keep the complexity of the opcode check down, and then it's simpler overall with a single function. Comment Actions
Done. This revision is now accepted and ready to land.Jul 7 2021, 12:09 AM Comment Actions Anything I can do to expedite the application? I do have more changes planned which are depending on/conflicting with this one... Comment Actions Oh, sorry. Yes this is good to go. Either you can request commit access, via https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access, or I am happy to commit it for you. If it is your first patch, then it may require someone with existing access to commit it, I'm not very sure how the policy on getting access usually goes. If you are happy for me to commit it, then I just need a way to attribute the patch. Something like "Daniel Egger <someone@somewhere.com>". Comment Actions
Please go ahead and commit it. There's a Signed-off-by: Daniel Egger <daniel@eggers-club.de> within the commit message of the patch but feel free to modify as needed. Comment Actions Ah that'll work great, thanks. I will probably commit it tomorrow morning when the buildbots are less red. Thanks for the patch. I look forward to seeing what else you have. Comment Actions
At the moment I'm struggling to add v4i8 and v2i16 support. ๐ Is there any chat channel or something where someone might help me laying the foundation for future work? Comment Actions 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. For the cases we do recognize, it's from scalar code either through ISel or the ARMParallelDSPPass. If you have control of the code, the best bet may be to just use the @llvm.arm.qadd8 intrinsics directly. This revision was landed with ongoing or failed builds.Jul 11 2021, 7:58 AM Closed by commit rG98c2e4115d8d: [ARM] Add lowering of uadd_sat to uq{add|sub}8 and uq{add|sub}16 (authored by therealprof, committed by dmgreen). ยท Explain Why This revision was automatically updated to reflect the committed changes. Comment Actions
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.
I am aware. ;)
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.
Revision Contents
Diff 356407 llvm/lib/Target/ARM/ARMISelLowering.h
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/lib/Target/ARM/ARMInstrInfo.td
llvm/lib/Target/ARM/ARMInstrThumb2.td
llvm/test/CodeGen/ARM/uadd_sat.ll
llvm/test/CodeGen/ARM/uadd_sat_plus.ll
llvm/test/CodeGen/ARM/usub_sat.ll
llvm/test/CodeGen/ARM/usub_sat_plus.ll
|
clang-format suggested style edits found: