search for: llvmti

I'm running into lots of problems with this call back. Mostly the problem occurs because this callback is used before types are legalized. However, the code generator does not have a 1-1 correspondence between all LLVM types and the codegen types. This leads to problems when getSetCCResultType is passed in an invalid type, but has a valid LLVM type attached to it. An example is <3 x

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From:

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

I searched the archives and found this from last month: I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== ---

* Neale Ferguson: > So the SimpleTy variable which is a SimpleTypeValue is behaving strangely. > It's found within a private definition: > > union { > uintptr_t V; > SimpleValueType SimpleTy; > const Type *LLVMTy; > }; > > The comment in the above fix indicates that in this 64-bit system the enum > needs to be 64-bits is correct,

On Aug 18, 2009, at 11:50 AM, Erick Tryzelaar wrote: > I was running into a problem with compiling llvm with gcc 4.4 on > fedora 11 with --enable-optimized. I was seeing this warning dozens of > times: > > /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In > member function > ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: >

Yes, that works much better. However, I fear the problem is more to do with trying to force enums to be a different size which appears not to be supported by most compilers. The IBM C++ compiler apparently has a #pragma which can be used to do it and gcc 4.3 seems to be happy with the hack described but as Duncan says trying to force this behavior in a union is probably less than desirable in the

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

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

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

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

Hello, > +static const uintptr_t minus_one = -1; -1 here is of signed int type. What if you will use -1ULL ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Neale, > Yes, that works much better. However, I fear the problem is more to do with > trying to force enums to be a different size which appears not to be > supported by most compilers. The IBM C++ compiler apparently has a #pragma > which can be used to do it and gcc 4.3 seems to be happy with the hack > described but as Duncan says trying to force this behavior in a union is

We have is a problem in getSetCCResult(), which we overload because we support setCC for vectors. However, where other targets can get away with merely converting the EVT that gets passed to getSetCCResult() to an integer type (which EVT conveniently provides a method to do), we need to convert to int AND promote to i32 (or, in some cases, i64). This requires doing something that the EVT

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,

Hi, > llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td > tblgen: IntrinsicEmitter.cpp:163: void EmitTypeForValueType(std::ostream&, > llvm::MVT::SimpleValueType): Assertion `false && "Unsupported ValueType!"' > failed. this came up before IIRC, but I don't remember the details - buggy system compiler? Try searching the archives. Also, if you

Hi, I am beginning the porting process for Linux on System z (aka IBM Mainframe). I thought I¹d build LLVM first with the c and cpp backends so that tools like TableGen would be created that I¹d then use to process the .td files that I¹ll be creating. So I used svn to grab the code from the repository and ran configure and make. However, the build breaks at this point: llvm[1]: Building

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.) -scooter On Tue, Feb 24, 2009 at 12:28 AM, Duncan Sands <baldrick at