Skip to content

Conversation

@fhahn
Copy link
Contributor

@fhahn fhahn commented Mar 22, 2025

foldAggregateConstructionIntoAggregateReuse iterates over the entries of SourceAggregates and the order of inserted instructions depends on the order of the iterator. Using a regular DenseMap can lead to non-deterministic value naming/numbering.

I don't think it can actually impact the generated binary, but it makes diffing IR more difficult. If desired, I could provide a test case showing the difference in naming.

foldAggregateConstructionIntoAggregateReuse iterates over the entries of
SourceAggregates and the order of inserted instructions depends on the
order of the iterator. Using a regular DenseMap can lead to
non-deterministic value naming/numbering.

I don't think it can actually impact the generated binary, but it makes
diffing IR more difficult. If desired, I could provide a test case showing
the difference in naming.
@fhahn fhahn requested review from dtcxzyw and goldsteinn March 22, 2025 20:52
@fhahn fhahn requested a review from nikic as a code owner March 22, 2025 20:52
@llvmbot llvmbot added llvm:instcombine Covers the InstCombine, InstSimplify and AggressiveInstCombine passes llvm:transforms labels Mar 22, 2025
@llvmbot
Copy link
Member

llvmbot commented Mar 22, 2025

@llvm/pr-subscribers-llvm-transforms

Author: Florian Hahn (fhahn)

Changes

foldAggregateConstructionIntoAggregateReuse iterates over the entries of SourceAggregates and the order of inserted instructions depends on the order of the iterator. Using a regular DenseMap can lead to non-deterministic value naming/numbering.

I don't think it can actually impact the generated binary, but it makes diffing IR more difficult. If desired, I could provide a test case showing the difference in naming.


Full diff: https://github.com/llvm/llvm-project/pull/132564.diff

1 Files Affected:

  • (modified) llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp (+1-1)
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp b/llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
index 6860a7cd07b78..f897cc7855d2d 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
@@ -1111,7 +1111,7 @@ Instruction *InstCombinerImpl::foldAggregateConstructionIntoAggregateReuse(
   // For each predecessor, what is the source aggregate,
   // from which all the elements were originally extracted from?
   // Note that we want for the map to have stable iteration order!
-  SmallDenseMap<BasicBlock *, Value *, 4> SourceAggregates;
+  SmallMapVector<BasicBlock *, Value *, 4> SourceAggregates;
   bool FoundSrcAgg = false;
   for (BasicBlock *Pred : Preds) {
     std::pair<decltype(SourceAggregates)::iterator, bool> IV =

@fhahn fhahn merged commit cfd53ff into llvm:main Mar 23, 2025
14 checks passed
@fhahn fhahn deleted the ic-use-mapvector branch March 23, 2025 11:17
llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Mar 23, 2025
foldAggregateConstructionIntoAggregateReuse iterates over the entries of
SourceAggregates and the order of inserted instructions depends on the
order of the iterator. Using a regular DenseMap can lead to
non-deterministic value naming/numbering.

I don't think it can actually impact the generated binary, but it makes
diffing IR more difficult.

PR: llvm/llvm-project#132564
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

llvm:instcombine Covers the InstCombine, InstSimplify and AggressiveInstCombine passes llvm:transforms

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants