similar to: [LLVMdev] Difference between vector and scalar legalization

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Hi Akira, On 01/06/12 02:27, Hatanaka, Akira wrote: > In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: > > 1314 case TargetLowering::Custom: > 1315 ReplaceNode(SDValue(Node, 0), > 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); > 1317 break; > > Is there a reason it doesn't check whether the

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 case. Reproduce

In LegalizeDAG.cpp, truncating stores are custom-lowered in line 1314-1317: 1314 case TargetLowering::Custom: 1315 ReplaceNode(SDValue(Node, 0), 1316 TLI.LowerOperation(SDValue(Node, 0), DAG)); 1317 break; Is there a reason it doesn't check whether the SDValue returned from TargetLowering::LowerOperation is null before it replaces the

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

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: > > I work on reverting it,

I believe this patch has broken a PPC app that I am tracking. Here is a reduced test case. Reproduce with llc -mattr=+Altivec -mcpu=g5. The backtrace looks like this: #0 0x9333ae42 in __kill () #1 0x9333ae34 in kill$UNIX2003 () #2 0x933ad23a in raise () #3 0x933b9679 in abort () #4 0x933ae3db in __assert_rtn () #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at

Evan: I work on reverting it, although, when I tried yesterday, it wasn't particularly clean (lots of rejected patches, presumably due to intervening commits.) Are you still getting the backtrace or is this just a case of incorrectly generated code? -scooter On Wed, Feb 25, 2009 at 10:09 AM, Evan Cheng <echeng at apple.com> wrote: > Things are still broken. Unfortunately llvm

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

Hi again, Kind people on #llvm helped me to utilize bugpoint to reduce the previously submitted test case. For record, it code be done with the following command: $ bugpoint -llc-safe test.ll The resulting IR is attached, and it is crashing in the same way. Is it a valid code? dmikushin at hp2:~/forge/kernelgen/branches/tests_lnt/behavior/sincos> llc test.ll.1 This action is not supported

Dear LLVM, I'm trying to understand why the attached IR code works for x86_64 target and fails for nvptx64, because of unimplemented expand during the target lowering. Any ideas? Just change the target triple to x86_64-unknown-unknown, and the same IR code could we successfully codegen-ed for x86_64. Thanks, - Dima. dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc GNU gdb

Hello, I'm working on extending the current PowerPC backend to handle a vector instruction set for floating-point operations (IBM's double-hummer instruction set used on the BG/P supercomputers). In this instruction set, each of the existing floating-point registers becomes the first of two vector elements. I am having trouble optimizing the BUILD_VECTOR operation for the case where I am

On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: >> >> This seems to break the convention. It should be the responsibility >> of the caller to further legalize the results. >> >> Evan > That makes sense. In that case I believe > SelectionDAGLegalize::LegalizeSetCCOperands > should be legalizing the result. The description of this function > says

Evan Cheng wrote: > On Jul 3, 2008, at 3:07 PM, Richard Osborne wrote: > >>> This seems to break the convention. It should be the responsibility >>> of the caller to further legalize the results. >>> >>> Evan >>> >> That makes sense. In that case I believe >> SelectionDAGLegalize::LegalizeSetCCOperands >> should be

The LegalizeDAG.cpp file has this code in SelectionDAGLegalize::PromoteNode: case ISD::BSWAP: { unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); Tmp1 = DAG.getNode(ISD::SRL, dl, NVT, Tmp1, DAG.getConstant(DiffBits, TLI.getShiftAmountTy()));

On my target store/load of f32 or i32 are equivalents. Previously I had duplicate instructions def in .td to map f32 and i32 to the same opcode. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote);

Hi. I am beginning to learn LLVM (using LLVM 2.3.0 on a Linux x86_64 machine) and wanted to check the status of the support of arbitrary size integers. To do so, I tried to modify the HowToUseJIT example by replacing the Int32Ty with another size (let's say 12 bits for the example). While it compiles ok, I get the following assert at run-time: HowToUseJIT: LegalizeDAG.cpp:4059:

I am getting an assert on a bad legalization. Assertion failed: Result.getValueType() == Op.getValueType() && "Bad legalization!", file ..\..\lib\CodeGen\SelectionDAG\LegalizeDAG.cpp, line 3976 Can someone explain to me what this means in term of backend code generation, how it might be occurring, and possible ways to fix this? I don't see how the value type of an

On Dec 22, 2009, at 2:38 PMPST, Bill Wendling wrote: > The LegalizeDAG.cpp file has this code in > SelectionDAGLegalize::PromoteNode: > > case ISD::BSWAP: { > unsigned DiffBits = NVT.getSizeInBits() - OVT.getSizeInBits(); > Tmp1 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::BSWAP, dl, NVT, Tmp1); > Tmp1 = DAG.getNode(ISD::SRL, dl,