[patch] Allow alias to point to an arbitrary ConstantExpr

Reid Kleckner rnk at google.com
Mon Jun 2 11:29:15 PDT 2014


+Aliases have a name and an aliasee that is either a global value or a
+constant expressision.

"expression"

+  // It is unfortunate that we have to use "char *" in here since this is
+  // always non NULL, but:
+  // * The C API expects a null terminated string, so we cannot use
StringRef.
+  // * The C API expects us to own it, so we cannot use a std:string.
+  // * For GlobalAliases we can fail to find the section and we have to
+  //   return "", so we cannot use a "const String &".

"String" is confusing, I'd spell out std::string.  Don't sweat this API,
because David is going to replace it soon with section IR.

+  const char *getSection() const;

+static GlobalValue *getSimpleAliasee(Constant *C) {

Can this be simplified with cast<Constant>(C->stripPointerCasts())?  I
wonder if we should have a Constant::stripPointerCasts() to hide the cast.

+const GlobalObject *getBaseObject(const Constant &C) {

ditto

-  const GlobalValue *UnderlyingGV = GV;
-  // If GV is an alias then use the aliasee to determine the wrapper type
-  if (const GlobalAlias *GA = dyn_cast<GlobalAlias>(GV))
-    UnderlyingGV = GA->getAliasee();
-  if (const GlobalVariable *GVar = dyn_cast<GlobalVariable>(UnderlyingGV))
{
-    if ((GVar->isConstant() && GV->hasLocalLinkage()) ||
-        (GVar->hasSection() &&
-         StringRef(GVar->getSection()).startswith(".cp.")))
-      return DAG.getNode(XCoreISD::CPRelativeWrapper, dl, MVT::i32, GA);
-    return DAG.getNode(XCoreISD::DPRelativeWrapper, dl, MVT::i32, GA);
-  }
-  return DAG.getNode(XCoreISD::PCRelativeWrapper, dl, MVT::i32, GA);
+
+  if (GV->getType()->getElementType()->isFunctionTy())
+    return DAG.getNode(XCoreISD::PCRelativeWrapper, dl, MVT::i32, GA);
+
+  const auto *GVar = dyn_cast<GlobalVariable>(GV);
+  if ((GV->hasSection() && StringRef(GV->getSection()).startswith(".cp."))
||
+      (GVar && GVar->isConstant() && GV->hasLocalLinkage()))
+    return DAG.getNode(XCoreISD::CPRelativeWrapper, dl, MVT::i32, GA);
+
+  return DAG.getNode(XCoreISD::DPRelativeWrapper, dl, MVT::i32, GA);

Just to check, there should be no behavioral change here, because
getSection now looks through aliases for us.

+// This is only used in aliases that we created and we know they have a
+// linear structure.
+static const llvm::GlobalObject *getAliasedGlobal(const llvm::GlobalAlias
&GA) {

Can this be simplified with stripPointerCastsNoFollowAliases() wrapped with
a loop that follows getAliasee while inserting aliases into Visited?  For
that matter, does stripPointerCasts infloop on an alias cycle?



On Mon, Jun 2, 2014 at 5:36 AM, Rafael EspĂ­ndola <rafael.espindola at gmail.com
> wrote:

> Rebased patches attached.
>
> On 29 May 2014 12:44, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
> > Moving from llvm-dev to llvm-commits now that all the dependencies
> > have been committed and the direction seems agreed upon.
> >
> > The attached patch changes GlobalAlias to point to an arbitrary
> > ConstantExpr and it is up to MC (or the system assembler) to decide if
> > that expression is valid or not.
> >
> > This reduces our ability to diagnose invalid uses and how early we can
> > spot them, but it also lets us do things like
> >
> > @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32),
> >                                  i32 ptrtoint (i32* @bar to i32)) to
> i32*)
> >
> >
> > An important implication of this patch is that the notion of aliased
> > global doesn't exist any more. The alias has to encode the information
> > needed to access it in its metadata (linkage, visibility, type, etc).
> >
> > The clang patch includes a walk of alias chains, but that should be OK
> > since clang knows the form of every alias it creates.
> >
> > The llvm patch also includes one as a local hack in the old JIT. That
> > is hopefully OK since we are about to delete it and it should handle
> > as many cases as before.
> >
> > Another consequence to notice is that getSection has to return a
> > "const char *". It could return a NullTerminatedStringRef if there was
> > such a thing, but when that was proposed the decision was to just uses
> > "const char*" for that.
> >
> > Cheers,
> > Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140602/d350dc75/attachment.html>


More information about the llvm-commits mailing list