tree f32c240033e323abfa41a222dfd476d875f72485
parent 2dd1514113f21770b0a0d71d42e4159e36f2216e
author Ege Beysel <beysel@roofline.ai> 1786113292 +0200
committer GitHub <noreply@github.com> 1786113292 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJqde0MCRC1aQ7uu5UhlAAA6LgQAA6TVgfUra55IRJU4CM+aLxx
 eiomIKWAsWFtudjYFLOrXbxAu8OR3SCBqkMFObnwroPWfIWLUWAAhe8SV+UzdwTo
 XovzxK+mtMZhxBK/FcQQett8IjKroBG/RcguIJwLZv7jVMidiS1gkX30oC+Y7YMh
 iBpdnGqk4EJN6uQXKCOKXhcZqHjMtUiShfkbwlznTWksXjaNjRrTYijelBCgPMcV
 rlLy20YEy5muBTQ8XsxsSjNoFmv6Ofvy0mP0rCozfCcx+nSoPDlzh85H9OZ0I5cO
 9N2LdQq01mqdMOu/CTjK95JsGyP7f7dpH1r+yHoVybHr1k8k3AMpP8/hPD8mFNTU
 MUKeTI7nUHz+cDtWNpxXuRG/u0pqh8htJRW4OJ06qqjTXKwiRKr+fv+w0QjSKRfA
 wVhDUwdHaPStA2L6nOmwW6xpWf7KXsQvnY3fhb4dQGC+YBnW/3DY69Z7D+ImHYCc
 iQR6+YRxp2z4T3pPAB0bsI6IqfV92enSnJ/rUa7pJCDQj8IVGETcroSs6PrsvubP
 91wMX4l48aJtLFd18qvPws+D0sKfQlqJVVy7GrwxtkrcOixrXf81lkEbAJ7sPEV7
 vDg4nCdBm4r2XgNdyrS5WnxgziAeOMR/1AIsNI2BVsc8z97CFnddcXYvZWisjbqJ
 ytO61d3MQ8q2KQoiaVdz
 =ewI7
 -----END PGP SIGNATURE-----
 

Integrate LLVM to llvm/llvm-project@480b2c9eb47f (#24793)

Bumpy `llvm-project` from `8c5193b41f2f` to `480b2c9eb47f`, no
carried-over or new reverts.

One adaptation was required:

llvm/llvm-project@9e43e04108dd stops arith-expand from expanding
`arith.maximumf/minimumf/maxnumf/minnumf` unless the new
`include-min-max-f` option is set. For VMVX, `ArithToVM` has conversion
patterns for `arith.maximumf/minimumf` but none for
`arith.maxnumf/minnumf`, so the `arith.maxnumf` emitted by the
`linalg.softmax` decomposition no longer legalized and `VMVX -> VM`
conversion failed in `tests/e2e/linalg/softmax.mlir`.

Setting `includeMinMaxF` on the VMVX arith-expand invocation restores
the previous behavior. `include-min-max-i` is left off because the VM
dialect has native integer min/max ops for both i32 and i64.

LLVMCPU has direct lowerings to the `llvm.intr.maximum/maxnum`.

Assisted-by: Claude Code and reviewed by me.

---------

Signed-off-by: Ege Beysel <beysel@roofline.ai>