Integrate LLVM at 1c023cb #22943
Merged
Integrate LLVM at 1c023cb #22943
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bjacob
force-pushed
the
integrates/llvm-20251218
branch
2 times, most recently
from
89af862 to
bc92f67
Compare
…SymbolOpInterface to implement operateOnSymbol in test-symbol-uses pass (#172675) (lonely eagle on 2025-12-18 20:58:30 +0800) (14 of 15) Signed-off-by: Benoit Jacob <[email protected]>
Integrate upstream changes to the `dropUnitDims` API into the `FoldUnitExtentDims` pass. The behavior remains the same for now. Signed-off-by: Lukas Sommer <[email protected]>
Signed-off-by: Lukas Sommer <[email protected]>
bjacob
force-pushed
the
integrates/llvm-20251218
branch
from
bc92f67 to
4a4a3bf
Compare
Signed-off-by: Benoit Jacob <[email protected]>
bjacob
force-pushed
the
integrates/llvm-20251218
branch
from
4a4a3bf to
054b836
Compare
bjacob
requested review from
IanWood1,
MaheshRavishankar and
benvanik
as code owners
Signed-off-by: Benoit Jacob <[email protected]>
MaheshRavishankar
approved these changes
Dec 19, 2025
bangtianliu
pushed a commit
to bangtianliu/iree
that referenced
this pull request
Dec 23, 2025
Integrate llvm/llvm-project@1c023cb This folds Lukas' commits from iree-org#22921. Thanks! Additional local change: adding `f16<->f64` conversions and `f64` `fma` to `libdevice` as these are now required by lowerings of `f16` multiply-add to targets without native `f16` support (typically CPU targets). * The symptom that this is fixing, is unresolved symbol errors at linking. * The regressing upstream PR is llvm/llvm-project#171904. * Rationale given there: it's necessary to go to `f64` to implement a perfectly accurate `f16` multiply-add without observable double-rounding. * We don't need to worry too much about the performance here: by definition, this code only happens when we use a data type that is not natively supported in hardware, so users who care about performance should not be on such a path anyway. This preexisting rationale is why the `libdevice` implementation of `f16` conversions favors simplicity over performance. Existing local reverts carried forward: * Local revert of llvm/llvm-project#169614 due iree-org#22649. * Also iree-org/llvm-project@dea9ec8 which had landed on top. --------- Signed-off-by: Benoit Jacob <[email protected]> Signed-off-by: Lukas Sommer <[email protected]> Co-authored-by: Lukas Sommer <[email protected]>
This was referenced Dec 24, 2025
keshavvinayak01
pushed a commit
that referenced
this pull request
Jan 27, 2026
Integrate llvm/llvm-project@1c023cb This folds Lukas' commits from #22921. Thanks! Additional local change: adding `f16<->f64` conversions and `f64` `fma` to `libdevice` as these are now required by lowerings of `f16` multiply-add to targets without native `f16` support (typically CPU targets). * The symptom that this is fixing, is unresolved symbol errors at linking. * The regressing upstream PR is llvm/llvm-project#171904. * Rationale given there: it's necessary to go to `f64` to implement a perfectly accurate `f16` multiply-add without observable double-rounding. * We don't need to worry too much about the performance here: by definition, this code only happens when we use a data type that is not natively supported in hardware, so users who care about performance should not be on such a path anyway. This preexisting rationale is why the `libdevice` implementation of `f16` conversions favors simplicity over performance. Existing local reverts carried forward: * Local revert of llvm/llvm-project#169614 due #22649. * Also iree-org/llvm-project@dea9ec8 which had landed on top. --------- Signed-off-by: Benoit Jacob <[email protected]> Signed-off-by: Lukas Sommer <[email protected]> Co-authored-by: Lukas Sommer <[email protected]> Signed-off-by: Keshav Vinayak Jha <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Integrate llvm/llvm-project@1c023cb
This folds Lukas' commits from #22921. Thanks!
Additional local change: adding
f16<->f64conversions andf64fmatolibdeviceas these are now required by lowerings off16multiply-add to targets without nativef16support (typically CPU targets).llvm.fma.f16double rounding issue when there is no native support llvm/llvm-project#171904.f64to implement a perfectly accuratef16multiply-add without observable double-rounding.libdeviceimplementation off16conversions favors simplicity over performance.Existing local reverts carried forward: