search for: simplevaluetypes

Hi, ABCRegister.td : def SGPR32 : RegisterClass<"ABC", [i32], 16, (add S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; def SFGPR32 : RegisterClass<"ABC", [f32], 16, (add S0, S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15 )>; ===== Instruction selection ends: ... t8: i32 = ADDrr t37, t32

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 =================================================================== ---

Because each channel contains 24-bit, so.. what is the llvm::SimpleValueType I should use for each channel? the current llvm::SimpleValueType contains i1, i8, i16, i32, i64, f32, f64, f80, none of them are fit one channel (24-bit). I think I can use i32 or f32 to represent each 24-bit channel, if the runtime result of some machine instructions exceeds 23-bit (1 bit is for sign), then it is an

24 bit is not unusual in the DSP world. I suppose int == 24 bit integer for some of these chips? There isn't a i24 simple type. However, you can create an extended integer type. See getExtendedIntegerVT. It's almost guaranteed you will have to change a chunk of target independent codegen to support the use of an extended type though. Evan On Nov 20, 2008, at 4:46 AM, Wei wrote:

I have a very strange and complicate H/W platform. It has many registers in one format. The register format is: ------------------------------ ---------------------------------------------------------------------------------------- | 24-bit | 24-bit | 24-bit | 24-bit |

Michel Salim wrote: > On Fri, Feb 6, 2009 at 8:42 PM, Tanya Lattner <tonic at nondot.org> wrote: >> LLVMers, >> >> The 2.5 pre-release is available for testing: >> http://llvm.org/prereleases/2.5/ >> > I'm updating the Fedora packaging of LLVM, and with the 02/20 > prerelease it fails to build on ppc64: > >

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

Why not model each channel as a separate physical register? Evan On Nov 17, 2008, at 6:36 AM, Wei wrote: > I have a very strange and complicate H/W platform. > It has many registers in one format. > The register format is: > > ------------------------------ > ---------------------------------------------------------------------------------------- > | 24-bit

On Fri, Feb 6, 2009 at 8:42 PM, Tanya Lattner <tonic at nondot.org> wrote: > LLVMers, > > The 2.5 pre-release is available for testing: > http://llvm.org/prereleases/2.5/ > I'm updating the Fedora packaging of LLVM, and with the 02/20 prerelease it fails to build on ppc64: http://koji.fedoraproject.org/koji/taskinfo?taskID=1148023 make[1]: Entering directory

This is similar to ATI's R300/R420 pixel shaders. I'm familiar with this hardware, but not really an LLVM expert (working on a code generator myself, but learning as I go). Do you have 24-bit integer operations, or just floating point? What about load/store? Are you looking to run large C programs with complex data structures, or just comparatively simple math functions (i.e. a

On Sep 23, 2011, at 1:38 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> It appears that tablegen is inferring the 'type' of an individual >> register by enumerating all the register classes it appears in. Some >> things, like using implicit defs in SDNodes, only works for registers >> with a unique type. My

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

Do you mean MVT::getIntegerVT? Because I can not find getExtendedIntegerVT in the llvm source codes. I am excited seeing this function, however I have the following more questions. 1) You mention I will have to change not small amount of target indenpendent codegen codes to support this extended type. Are there any document to describe how to do such kind modification? I see there is a

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'm trying to do a Debug build for the 1st time and I keep getting this assertion: llvm-tblgen: CodeGenDAGPatterns.cpp:64: llvm::EEVT::TypeSet::TypeSet(llvm::ArrayRef<llvm::MVT::SimpleValueType>): Assertion `!VTList.empty() && "empty list?"' failed. I do not know what list this assertion is referring to. Does anyone know? I always did Release builds before

Hi all. I'm looking for a ways of defining register files with non-standard machine value type in tablegen. The value types not covered by SimpleValueType enum. For example (from the top of my head) 25 bit integers, or 8 way 18 bit integers. These types going to be used with intrinsics so I also need appropriate C custom types defined. I wonder if I can describe those in tablegen files or do

Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

I have 24-bit integer operations as well as 24-bit floating point (s7.16) operations. The H/W supports load/store instructions, however, they does suggest us not to use these load/store instructions besides debugging purpose. That is to say, you can imagine we don't have load/store instructions, we don't have memory, we just have registers. I will run OpenGL shading laugnage programs on

On Nov 22, 2008, at 7:48 AM, Wei wrote: > Do you mean MVT::getIntegerVT? Because I can not find > getExtendedIntegerVT in the llvm source codes. > I am excited seeing this function, however I have the following more > questions. See ValueTypes.h and ValueTypes.cpp. Also this example: @str = internal constant [4 x i8] c"%d\0A\00" define void @foo2(i24 %a, i24 %b) nounwind