Subzero: Fix nondeterministic behavior in constant pool creation.
This issue was discovered as the result of a spurious "make check-lit" failure in undef.ll.
The problem is that constant pool label strings depend on the order the constants are created, and this order can be different with multithreaded translation.
Even -filetype=obj is affected by this, because the label string is put into the ELF .o file. This means that different runs of Subzero on the same input could potentially produce slightly different output.
The solution is to base the label name on the actual value of the constant. We do this by using the hex representation of the constant, rather than the sequence number of the constant within the pool. This actually simplifies things a bit, as we no longer need to track the sequence number.
In addition, for floating-point constant labels in asm-verbose mode, include a human-readable rendering of the value in the label name.
BUG= none
R=kschimpf@google.com
Review URL: https://codereview.chromium.org/1386593004 .
diff --git a/src/IceGlobalContext.cpp b/src/IceGlobalContext.cpp
index c7497da..24002d6 100644
--- a/src/IceGlobalContext.cpp
+++ b/src/IceGlobalContext.cpp
@@ -130,7 +130,7 @@
auto Iter = Pool.find(Key);
if (Iter != Pool.end())
return Iter->second;
- ValueType *Result = ValueType::create(Ctx, Ty, Key, NextPoolID++);
+ ValueType *Result = ValueType::create(Ctx, Ty, Key);
Pool[Key] = Result;
return Result;
}
@@ -157,7 +157,6 @@
std::unordered_map<KeyType, ValueType *, std::hash<KeyType>,
KeyCompare<KeyType>>;
ContainerType Pool;
- uint32_t NextPoolID = 0;
};
// UndefPool maps ICE types to the corresponding ConstantUndef values.
@@ -170,12 +169,11 @@
ConstantUndef *getOrAdd(GlobalContext *Ctx, Type Ty) {
if (Pool[Ty] == nullptr)
- Pool[Ty] = ConstantUndef::create(Ctx, Ty, NextPoolID++);
+ Pool[Ty] = ConstantUndef::create(Ctx, Ty);
return Pool[Ty];
}
private:
- uint32_t NextPoolID = 0;
std::vector<ConstantUndef *> Pool;
};