Same as D93833, use zanyext to treat any_extends as zero extends during lowering to create addw/addl/subw/subl nodes.
Details
Diff Detail
Event Timeline
Hello. Yeah those are related. I was using an AND here to get the same effect, but this is more likely to come up from the truncs in that patch in practice. D93834 is the mull part of handling any_extends. (It unfortunately doesn't entirely fix both the cases there because we end up turning one of the any_extends into a zext load, and are left with a smull of a sext load and zext load).
Long story short - I was trying to port the HADD code from AArch64 so it could be used in MVE too, but in a slightly different way to how they are currently done in the aarch64 backend. Instead of starting at a trunk it started at the shift like MULH lowering. Unfortunately llvm loves turning arithmetic shifts into logical shifts, but it's only valid to match to a hadd in that case if the top bits are not demanded. Which is where I saw D56387, to mark the top bits as not demanded. But we don't currently handle the any extends well in either Arm or AArch64.
I may try and do that HADD lowering differently, maybe more like is done at the moment. It needs some MVE fixes first in any rate, But I figured this was worth doing on it's own. And I believe that treating anyextend as a zext is always fine for lowering (if not always optimal, if a sext/anyextend pair could be folded too).