[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]

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