[llvm] wasm: recognize `any_true` and `all_true` (PR #155885)

Folkert de Vries via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 20 02:41:21 PDT 2026


folkertdev wrote:

> Why doesn't the combiner fall back to the original implementation when your optimisation fails?

due to https://github.com/llvm/llvm-project/pull/155885#issuecomment-3865133335 and preceding comments

> > > > Custom lowering can report the instance as legal, or defer to the default expansion.
> > > 
> > > 
> > > It's just that the default expansion is different if you expand early or late that's throwing me off.
> > 
> > 
> > Yes, the legalization behavior if it happens during type legalization vs. on legal types is a huge pain. This was one of the DAG design mistakes
> 
> To clarify, for vector reductions specifically, we have either an _IR level_ expansion using shuffle trees, or legalization via VECREDUCE opcodes. The SDAG level legalization is not limited to using shuffles in the way the IR level is, so it will typically legalize via vector splitting.
> 
> Generally the IR expansions are something of a legacy mechanism that should eventually be replaced with the SDAG legalization approach.

> The introduction of all those extracts is definitely a red flag, so this approach doesn't look sound to me.

Well I guess the question is at what point the scalar version is more optimal than the non-scalar function. As I understand it the wasm `shuffle`s are relatively expensive, so shorter code that uses a shuffle might in fact perform worse than longer code using only simple scalar operations. I'm not sure where to draw the line on that.


https://github.com/llvm/llvm-project/pull/155885


More information about the llvm-commits mailing list