Sam Parker (Jun 05 2024 at 09:03): Sam Parker (Jun 05 2024 at 09:03):Hi!
I'm trying to make LLVM produce wasm code that can enable lowering to FP pairwise add, the patch is here:
https://github.com/llvm/llvm-project/pull/93948. The patch would also change the shuffle patterns used to lower integer reductions, so I was wondering whether you're relying on the current LLVM behaviour for the iadd_pairwise operation?
cheers,
Alex Crichton (Jun 05 2024 at 13:47):Given our abstraction level of wasm as opposed to llvm if llvm changes output then we should in theory still be able to run everything, the only risk we have is if a pattern changes and it falls off a "fast path" for a particular backend. In that case it probably depends a bit more concretely on what's changing here?
For iadd_pairwise I don't think anything would be affected as we only use that for *extadd_pairwise* and *dot*, so I don't think it'd break that particular instruction (it's also private in the sense that it's a cranelift instruction and no wasm instruction has a directly lowering to it)
Alex Crichton (Jun 05 2024 at 13:49):Put another way if LLVM changes output then that's mostly just more patterns for us to recognize. We don't have an overly large number of patterns so if output changes it'll probably slow down some code, but we can add more patterns to recover the speedup if necessary
Sam Parker (Jun 05 2024 at 14:10):Good, sounds like the IR generation won't be affected then. I intend on changing the shuffle indices so they represent the combining of adjacent elements, whereas LLVM currently generates a combination of the top and bottom half of a vector. So, it may still affect backends if they currently perform pattern matching for int add reductions on the existing shuffle indices.
Alex Crichton (Jun 05 2024 at 14:15):indeed yeah!
Most of our pattern-matches we currently are manually done and done on a case-by-case basis. We don't have a continuous benchmark suite we're looking at for example or source code like Rust and testing the output, all of our tests are wasm-to-clif or wasm-to-machine-code which wouldn't be affected by this
Alex Crichton (Jun 05 2024 at 14:15):basically this probably would break something somewhere, but that's ok we can fix it as it arises!
Sam Parker (Jun 05 2024 at 14:16):Ok, great. Thanks.
Notification Bot (Sep 08 2024 at 13:43):Till Schneidereit has marked this topic as resolved.
Last updated: Nov 26 2024 at 01:30 UTC