[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/

Chris Lattner
Wed, 25 Feb 2009 00:06:37 -0000

On Feb 24, 2009, at 9:35 AM, Scott Michel wrote:

> Duncan:
>
> I'm still stymied how this whole thread ended up about shuffle
> vector nodes, when the original problem was my build vector patch.
> I'm still working on backing the build vector patch out (it isn't
> clean with all of the intervening commits and I have pressing
> management tasks which command my attention.)

Scott,

You're absolutely right.  I got very very confused early on and that
completely derailed the whole discussion.  I'm sorry for being an
idiot, I must have had crossed wires.

Now that I actually understand that your goal here is to handle
*buildvectors* not "the buildvector argument to a shuffle node", I
understand a lot better what you're trying to do (and agree that it
has nothing to do with shuffles!).

However, I still prefer a different approach.  Are you familiar with
the IntrinsicInst class and things like DbgStopPointInst?  The basic
jist of it is that they are "pseudo classes" that are used with
dyn_cast etc that provide very useful helpers.

In the case of LLVM IR and debug stoppoint, a stoppoint is just an
llvm call instruction which happens to call the llvm.stoppoint
intrinsic. The DbgStopPointInst class "matches" in this case, allowing
you to use code like this:

if (DbgStopPointInst *I = dyn_cast< DbgStopPointInst>(someinst)) {
    print(I->getLine());
}

Where getLine() is a very nice helper function.

What do you think about making BuildVectorSDNode work exactly like
this?  That way, BUILD_VECTOR nodes are just normal SDNodes, but we
can still use:

if (BuildVectorSDNode *BV = dyn_cast< BuildVectorSDNode>(N)) { // only
works if the opcode is ISD::BUILD_VECTOR
   if (BV->isSplat(info,returned, byref))
      do stuff with info.
}

This makes the BuildVectorSDNode just a nice place to put the various
methods for inspecting build vector but doesn't require the uniquing
machinery to know about it, and means that things like SplatBits,
SplatUndef etc aren't instance variables.

What do you think?

Again, I'm am really really really sorry for the confusion, I did not
intend to derail the entire discussion with nonsense :( :(

-Chris