Don't passively concatenate MDNodes
I have audited all the callers of concatenate and none require duplicate entries to service concatenation. These duplicates serve no purpose but to needlessly embiggen the IR. N.B. Layering getMostGenericAliasScope on top of concatenate makes it O(nlogn + mlogm) instead of O(n*m). llvm-svn: 278836
This commit is contained in:
parent
0761b5253d
commit
fa0f1e660b
|
@ -16,6 +16,7 @@
|
||||||
#include "MetadataImpl.h"
|
#include "MetadataImpl.h"
|
||||||
#include "SymbolTableListTraitsImpl.h"
|
#include "SymbolTableListTraitsImpl.h"
|
||||||
#include "llvm/ADT/STLExtras.h"
|
#include "llvm/ADT/STLExtras.h"
|
||||||
|
#include "llvm/ADT/SetVector.h"
|
||||||
#include "llvm/ADT/SmallSet.h"
|
#include "llvm/ADT/SmallSet.h"
|
||||||
#include "llvm/ADT/StringMap.h"
|
#include "llvm/ADT/StringMap.h"
|
||||||
#include "llvm/IR/ConstantRange.h"
|
#include "llvm/IR/ConstantRange.h"
|
||||||
|
@ -862,14 +863,12 @@ MDNode *MDNode::concatenate(MDNode *A, MDNode *B) {
|
||||||
if (!B)
|
if (!B)
|
||||||
return A;
|
return A;
|
||||||
|
|
||||||
SmallVector<Metadata *, 4> MDs;
|
SmallSetVector<Metadata *, 4> MDs(A->op_begin(), A->op_end());
|
||||||
MDs.reserve(A->getNumOperands() + B->getNumOperands());
|
MDs.insert(B->op_begin(), B->op_end());
|
||||||
MDs.append(A->op_begin(), A->op_end());
|
|
||||||
MDs.append(B->op_begin(), B->op_end());
|
|
||||||
|
|
||||||
// FIXME: This preserves long-standing behaviour, but is it really the right
|
// FIXME: This preserves long-standing behaviour, but is it really the right
|
||||||
// behaviour? Or was that an unintended side-effect of node uniquing?
|
// behaviour? Or was that an unintended side-effect of node uniquing?
|
||||||
return getOrSelfReference(A->getContext(), MDs);
|
return getOrSelfReference(A->getContext(), MDs.getArrayRef());
|
||||||
}
|
}
|
||||||
|
|
||||||
MDNode *MDNode::intersect(MDNode *A, MDNode *B) {
|
MDNode *MDNode::intersect(MDNode *A, MDNode *B) {
|
||||||
|
@ -890,14 +889,7 @@ MDNode *MDNode::getMostGenericAliasScope(MDNode *A, MDNode *B) {
|
||||||
if (!A || !B)
|
if (!A || !B)
|
||||||
return nullptr;
|
return nullptr;
|
||||||
|
|
||||||
SmallVector<Metadata *, 4> MDs(B->op_begin(), B->op_end());
|
return concatenate(A, B);
|
||||||
for (Metadata *MD : A->operands())
|
|
||||||
if (!is_contained(B->operands(), MD))
|
|
||||||
MDs.push_back(MD);
|
|
||||||
|
|
||||||
// FIXME: This preserves long-standing behaviour, but is it really the right
|
|
||||||
// behaviour? Or was that an unintended side-effect of node uniquing?
|
|
||||||
return getOrSelfReference(A->getContext(), MDs);
|
|
||||||
}
|
}
|
||||||
|
|
||||||
MDNode *MDNode::getMostGenericFPMath(MDNode *A, MDNode *B) {
|
MDNode *MDNode::getMostGenericFPMath(MDNode *A, MDNode *B) {
|
||||||
|
|
|
@ -40,10 +40,10 @@ return: ; preds = %if.end, %if.then
|
||||||
; CHECK: ![[TBAA]] = !{![[TAG1:[0-9]+]], ![[TAG1]], i64 0}
|
; CHECK: ![[TBAA]] = !{![[TAG1:[0-9]+]], ![[TAG1]], i64 0}
|
||||||
; CHECK: ![[TAG1]] = !{!"int", !{{[0-9]+}}, i64 0}
|
; CHECK: ![[TAG1]] = !{!"int", !{{[0-9]+}}, i64 0}
|
||||||
; CHECK: ![[RANGE]] = !{i32 10, i32 25}
|
; CHECK: ![[RANGE]] = !{i32 10, i32 25}
|
||||||
; CHECK: ![[ALIAS_SCOPE]] = !{![[SCOPE0:[0-9]+]], ![[SCOPE1:[0-9]+]], ![[SCOPE2:[0-9]+]]}
|
; CHECK: ![[ALIAS_SCOPE]] = !{![[SCOPE0:[0-9]+]], ![[SCOPE2:[0-9]+]], ![[SCOPE1:[0-9]+]]}
|
||||||
; CHECK: ![[SCOPE0]] = distinct !{![[SCOPE0]], !{{[0-9]+}}, !"scope0"}
|
; CHECK: ![[SCOPE0]] = distinct !{![[SCOPE0]], !{{[0-9]+}}, !"scope0"}
|
||||||
; CHECK: ![[SCOPE1]] = distinct !{![[SCOPE1]], !{{[0-9]+}}, !"scope1"}
|
|
||||||
; CHECK: ![[SCOPE2]] = distinct !{![[SCOPE2]], !{{[0-9]+}}, !"scope2"}
|
; CHECK: ![[SCOPE2]] = distinct !{![[SCOPE2]], !{{[0-9]+}}, !"scope2"}
|
||||||
|
; CHECK: ![[SCOPE1]] = distinct !{![[SCOPE1]], !{{[0-9]+}}, !"scope1"}
|
||||||
; CHECK: ![[NOALIAS]] = !{![[SCOPE3:[0-9]+]]}
|
; CHECK: ![[NOALIAS]] = !{![[SCOPE3:[0-9]+]]}
|
||||||
; CHECK: ![[SCOPE3]] = distinct !{![[SCOPE3]], !{{[0-9]+}}, !"scope3"}
|
; CHECK: ![[SCOPE3]] = distinct !{![[SCOPE3]], !{{[0-9]+}}, !"scope3"}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue