[PATCH] Implement function prefix data as an IR feature.

Chris Lattner clattner at apple.com
Mon Jul 29 22:24:45 PDT 2013


On Jul 20, 2013, at 6:40 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

> Previous discussion:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html
> 
> http://llvm-reviews.chandlerc.com/D1191


This is gross, but I'm not morally opposed to this approach. :-)

Some questions:
 - Is this actually sufficient to implement support for GHC's TNTC optimization?  What else is it relevant for?
 - Given that this is completely target specific, is there any value in having some targets (e.g. not darwin) emit the blob *before* the function's label?  This would avoid the need to conditional branch around the blob.
 - What is the behavior of inlining and other IPO w.r.t. this?  If this requires disabling all inlining and other IPO, then we need to know how to model it and I'd like to know how frontends are going to use it.
 - In Function.h, this is really unfortunate:

+  bool hasPrefixData() const {
+    return getNumOperands() != 0;
+  }
+
+  Constant *getPrefixData() const {
+    assert(hasPrefixData());
+    return cast<Constant>(Op<0>());
+  }
+
+  void setPrefixData(Constant *PrefixData);

We want to keep the sizeof(Function) as small as possible, and this feature will almost never be used.  I'd much rather see this be stored with a single bit in Function::SubclassOptionalData (from Value) that indicates "has entry in an on-the-side hash table" (and also is used to implement hasPrefixData()) and store the Constant* in the hashtable.

 - Should this be modeled as some kind of crazy attribute?  That gives you a *different* place to unique it into and also would avoid punishing clients that aren't using it.

-Chris



More information about the llvm-commits mailing list