[PATCH] Cleaning up static initializers in InterferenceCache by moving the NoInterference static object into the class.

Chandler Carruth chandlerc at gmail.com
Fri Oct 10 15:18:33 PDT 2014


================
Comment at: lib/CodeGen/InterferenceCache.h:174
@@ -173,3 +173,3 @@
     BlockInterference *Current;
-    static BlockInterference NoInterference;
+    BlockInterference NoInterference;
 
----------------
beanz wrote:
> chandlerc wrote:
> > I don't think you should make the Cursor object larger here. One of three options should be employed:
> > 
> > 1) If possible, just construct a null temporary BlockInterference object where one is needed, or provide a factor function to do so.
> > 2) Alternatively (perhaps if that fails because it needs to have identity), make this a static *constant* (ie, constant initialized, should be possible from glancing at it). You could even make it a constexpr when we have support for that.
> > 3) If nothing else works, store it in the Entry, and reach it via the CacheEntry pointer.
> Unfortunately I don't think any of these options work without significant reworking of the code.
> 
>   # We can't construct a null temporary because the way this code works is based on having a pointer to the BlockInterference object.
>   # BlockInterference objects can't be statically initialized because they have user defined constructors and contain SlotIndex members. I don't think we can statically initialize those without constexpr.
>   # Unfortunately it can't be in the CacheEntry either because the only time this is used is when CacheEntry is null.
> 
> Thoughts?
> 
> 
Mostly frustration. ;] This code isn't making this easy.

The code clearly isn't *using* the SlotIndex members for the "no" case so I think this is just a badly designed set of data structures. I think you'll have to do the substantial changes here.

I would try to remove the use of a pointer to a special BlockInterference object as the sigil for "no interference". Instead I would try to use a null pointer or a separate flag (potentially embedded into the pointer via PointerUnion).

Sorry, this one just looks like one of the hard ones.

http://reviews.llvm.org/D5609






More information about the llvm-commits mailing list