[PATCH] Implement ADRP CSE for global symbols
Tim Northover
t.p.northover at gmail.com
Sat Apr 19 10:34:28 PDT 2014
Hi Jiangning,
This sounds like a good idea. I've got a couple of smaller comments:
================
Comment at: test/CodeGen/AArch64/global_merge_2.ll:1
@@ +1,2 @@
+; RUN: llc < %s -mtriple=aarch64-none-linux-gnu -global-merge-on-external=true | FileCheck %s
+
----------------
And speaking of tests, perhaps this would be a good time to promote GlobalMerge to something that can be run through opt and use that to do the testing.
================
Comment at: lib/Transforms/Scalar/GlobalMerge.cpp:287-290
@@ -248,2 +286,6 @@
+ // Merge is safe for "normal" internal or external globals only
+ if (!((EnableGlobalMergeOnExternal && I->hasExternalLinkage())
+ || I->hasInternalLinkage())
+ || I->isDeclaration() || I->isThreadLocal() || I->hasSection())
continue;
----------------
This might be clearer split up. I know my brain starts to melt when I see massive nested conditionals like this. Perhaps linkage conditions vs intrinsic blockers?
================
Comment at: lib/IR/Globals.cpp:277-279
@@ +276,5 @@
+ while (C) {
+ if (const GlobalAlias *GA = dyn_cast<GlobalAlias>(C)) {
+ C = GA->getAliasee();
+ } else if (const ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) {
+ if (CE->getOpcode() == Instruction::GetElementPtr) {
----------------
Are these clauses tested? I don't see any aliases or GEPs in your examples. I also vaguely remember Rafael saying that a GEP-based alias wasn't intended to be supported, though I wouldn't swear to it (and I'm fuzzy on exactly why it's a bad idea).
http://reviews.llvm.org/D3432
More information about the llvm-commits
mailing list