search for: buildvector

...> wrote: > > It's basically as Chris said; there will be a ShuffleVectorSDNode, > and appropriate helper functions, node profile, and DAGCombiner > support. > > Fine. For vector shuffles. But again, what about vector constants, > e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable > subclass to have for encapsulating constant vectors (should be > renamed, but hey, it's what it's called today.) You're talking about two very very very different things: shuffle_vector "masks" and constant vectors. Constant vectors...

...; >> >> It's basically as Chris said; there will be a ShuffleVectorSDNode, and >> appropriate helper functions, node profile, and DAGCombiner support. >> > > Fine. For vector shuffles. But again, what about vector constants, e.g., > v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable subclass to > have for encapsulating constant vectors (should be renamed, but hey, it's > what it's called today.) > > > You're talking about two very very very different things: shuffle_vector > "masks" and constant vectors. >...

...tors), but that also contains an array of > ints in the node (not as operands). ... > The important part of #3 is that we really want an array of ints > (using -1 for undef) for the shuffle mask, not "operands". This > eliminates the nastiness we have now were we need a buildvector, and > it eliminates the dance we have to prevent the build vector from being > legalized, and prevent the integer operands to it from being legalized. This is PR2957 (which originally suggested a variadic SDNode, but it quickly became clear that an array of ints is better). It would be...

...ing than before: $ llvm-as < test/CodeGen/Generic/select-cc.ll | llc Formal argument #0 has unhandled type i64 Stack dump: 0. Program arguments: llc 1. Running pass 'ARM Instruction Selection' on function '@vector_select' Aborted $ llvm-as < test/CodeGen/X86/dagcombine-buildvector.ll | llc Formal argument #1 has unhandled type i64 Stack dump: 0. Program arguments: llc 1. Running pass 'ARM Instruction Selection' on function '@test' Aborted I have tested this on a overo-earth ti omap3 hardware Linux overo 2.6.28-omap1 #1 Mon Mar 2 08:40:39 PST 2009 armv7...

...o contains an array of > > ints in the node (not as operands). > ... > > The important part of #3 is that we really want an array of ints > > (using -1 for undef) for the shuffle mask, not "operands". This > > eliminates the nastiness we have now were we need a buildvector, and > > it eliminates the dance we have to prevent the build vector from being > > legalized, and prevent the integer operands to it from being legalized. > > This is PR2957 (which originally suggested a variadic SDNode, but it > quickly became clear that an array of ints is b...

...; It's basically as Chris said; there will be a ShuffleVectorSDNode, >> and appropriate helper functions, node profile, and DAGCombiner >> support. >> >> Fine. For vector shuffles. But again, what about vector constants, >> e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a >> reasonable subclass to have for encapsulating constant vectors >> (should be renamed, but hey, it's what it's called today.) > > You're talking about two very very very different things: > shuffle_vector "masks" and constant vecto...

...nts in the node (not as operands). 4. Move the helper functions from #2 back into ShuffleVectorSDNode. The important part of #3 is that we really want an array of ints (using -1 for undef) for the shuffle mask, not "operands". This eliminates the nastiness we have now were we need a buildvector, and it eliminates the dance we have to prevent the build vector from being legalized, and prevent the integer operands to it from being legalized. Your patch doesn't get us further towards this eventual design point, which is why I prefer it to be reverted. -Chris

...tebegeman at me.com> wrote: > > It's basically as Chris said; there will be a ShuffleVectorSDNode, and > appropriate helper functions, node profile, and DAGCombiner support. > Fine. For vector shuffles. But again, what about vector constants, e.g., v4i32 <0, 1, 2, 3, 4>? BuildVectorSDNode is still a reasonable subclass to have for encapsulating constant vectors (should be renamed, but hey, it's what it's called today.) You can have a static method on SDNode that took an SDNode, checked if it > was a build vector, and calculated whatever splat information you wanted...

...o contains an array of > > ints in the node (not as operands). > ... > > The important part of #3 is that we really want an array of ints > > (using -1 for undef) for the shuffle mask, not "operands". This > > eliminates the nastiness we have now were we need a buildvector, and > > it eliminates the dance we have to prevent the build vector from > being > > legalized, and prevent the integer operands to it from being > legalized. > > This is PR2957 (which originally suggested a variadic SDNode, but it > quickly became clear that an arra...

...gt; On Feb 22, 2009, at 3:36 PM, Scott Michel wrote: >> >> Author: pingbak >>> Date: Sun Feb 22 17:36:09 2009 >>> New Revision: 65296 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=65296&view=rev >>> Log: >>> Introduce the BuildVectorSDNode class that encapsulates the >>> ISD::BUILD_VECTOR >>> instruction. The class also consolidates the code for detecting >>> constant >>> splats that's shared across PowerPC and the CellSPU backends (and >>> might be >>> useful for other...

Things are still broken. Unfortunately llvm test suite does not contain enough vector code to fully test this. Can you revert the patch first? Evan On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members > and passes results back via reference parameters. > > > -scooter > > On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> > wrote: > I believe this patch has broken a PPC app that I am tracki...

...9;m just not groking how moving isSplat to SDNode eliminates > BUILD_VECTOR or deals with constant vector formation. You can have a static method on SDNode that took an SDNode, checked if it was a build vector, and calculated whatever splat information you wanted. There's no need for BuildVectorSDNode for this particular functionality. > I like the idea of a ShuffleVectorSDNode (moves things in the > direction of a bijective ISD to SDNode mapping), but eliminating > BuildVectorSDNode in its entirety doesn't deal with constant and > variable vectors. LLVM has no va...

...ll broken. Unfortunately llvm test suite does not contain > enough vector code to fully test this. Can you revert the patch first? > Evan > > On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members and passes > results back via reference parameters. > > > -scooter > > On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> I believe this patch has broken a PPC app that I am tracki...

Evan: I did not encounter this back trace before I committed the newest BuildVectorSDNode patch, which removed all class instance members and passes results back via reference parameters. -scooter On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > I believe this patch has broken a PPC app that I am tracking. Here is a > reduced test cas...

Scott, In case you missed it, I reimplemented your BuildVectorSDNode::isConstantSplat method following the suggestions from Chris. The revised version passes "make check" for llvm. Assuming that it also passes Evan's tests, I think it should also do what you need for CellSPU. On Feb 25, 2009, at 12:16 PM, Scott Michel wrote: > Evan:...

After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel

Current dragonegg svn has all of the -fplugin-arg-dragonegg-enable-gcc-optzns bugs for usage with -ffast-math -O3 addressed except for those related to PR2314. Using the -fno-tree-vectorize option, we can evaluate the current state of -fplugin-arg-dragonegg-enable-gcc-optzns with the Polyhedron 2005 benchmarks compared to stock dragonegg and stock gcc 4.5.4. The runtime benchmarks below show that

...classes for constant splat detection, >> since it's functionality specific to building vectors. >> > > Eventually we need to add a ShuffleSDNode class for other reasons. Parking > it on SelectionDAG or SDNode is not a good place to put it. Ok, so that's a subclass of BuildVectorSDNode or the ShuffleSDNode class is passed one or more BuildVectorSDNode operands (vide infra.) > c) Future work. At some point (or another), having target-specific SDNode >> polymorphism is an issue that has to be addressed, in light of the vector >> swizzling support conversation...

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

I'm not currently setup to be able to run the A/B comparison tests that test-suite relies upon. Fhourstones-3.1 looks to be the simplest. If you can send me the two .o files from either EABI or Darwin, I can dig into why this went wrong for you. deep On Thu, Feb 26, 2009 at 3:53 PM, Evan Cheng <echeng at apple.com> wrote: > Sorry I haven't gotten back to you earlier. I have