[llvm-commits] New classes for PR1255: Should enhance LLVM switch instruction to take case ranges.

[Chris Lattner]

On Feb 14, 2012, at 3:39 AM, Stepan Dyatkovskiy wrote:

> Hi, Chris.
> You last thoughts relative to pr1255 was here:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120102/134424.html

Aha, I thought that I had suggested arrays/vectors somewhere.  Unfortunately, it doesn't work well because arrays all want the element type to be the same, having some that are scalars and some that are vectors isn't kosher.

>> Please remind me why it makes sense to use ConstantArray (or something like it) here.  It seems that the case values of the switch could be very reasonably represented with APInts, eliminating the Value*'s for the case values all together (which is what I recommended in Comment 15 of PR1255).  OTOH, I do vaguely remember making the comment about arrays and vectors in some PR (but can't find it).  Thinking about this a third time now, I really think that avoiding Constant*'s is the right thing to do.
> What is the main reason to use APInts?

There are a bunch of reasons.  For one, operands (including in a ConstantArray) are very expensive/heavyweight: sizeof(Use) = 64 bytes.  APInt is lighter weight: sizeof(APInt) = 8 bytes.

The other reason is one of purity: these are not IR values that can be used and manipulated like other values.  There are no defs and uses here.  The case values are purely an implementation detail of the switch instruction, so they should not be Value*'s or Use's.

> I have some half-implemented version with APInts. IMHO, I looks not very good, since it goes agains LLVM architecture: SwitchInst will first instruction that contains some values that are not inherited from the Value.

I'm not sure what you mean by that.  PHINode contains an unsigned.  SwitchInst even has an unsigned.  :)

The point of this is that the case value are not Value*'s.  They are not something that should have defs and uses.  You should not be able to use getOperand() to get at the APInts.

> I was need to do a set of workarounds adapting LLVM infrastructure to this feature: back-ends, asm-writer, lazy-values, Verifier.cpp with its original assertions and so on. APInt numbers will like an aliens from another planet, since the will need to work with entities that are from LLVMContext, and often we need to move it back using ConstantInt::get(...). If you have a time you can look at second draft patch attached to this post (cr-0.5.0). I made it two months ago or so on. It also contains changes in indexing I already applied, filtering it you can see what will wait LLVM if we will use APInt for case values. Patch is really huge, just look how SimplifyCFG, AsmWriter and BitcodeWriter will changed.

I'm not sure what you mean here.  The first thing that codegen does today is get the APInt out of a ConstantInt.  Removing the layer should simplify a number of things, particularly if SwitchInst has a good set of helper methods.

-Chris