similar to: [LLVMdev] Pointer Vs integer register classes.

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Pointer Vs integer register classes."

2013 Jun 24
1
[LLVMdev] Register Class assignment for integer and pointer types
2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk> > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we > have an iPTR256 for our fat pointers. This causes some problems with > constraints, because the way that TableGen resolves constraints is not > expected to handle multiple pointer types. We've added a flag that can be >
2009 Mar 10
1
[LLVMdev] 2.5 Pre-release1 available for testing
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: > >
2017 Jul 11
2
Using new types v32f32, v32f64 in llvm backend not possible
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
2009 Jun 17
0
[LLVMdev] help with tablegen
In order to make metadata useful to the backend, I'd like to permit intrinsics to be written that take metadata-typed objects. To allow this, I decided to try adding a new machine value type right next to isVoid. I updated both ValueTypes.td and ValueTypes.h as well as TableGen/IntrinsicEmitter.cpp and TableGen/CodeGenTarget.cpp where they have switch(mvt). The actual patch is attached.
2017 Jul 11
2
Using new types v32f32, v32f64 in llvm backend not possible
Thank you so much. it run fine. Can you please resolve following issue; I now have support for v2048i32 but my backend supports v64i32 so ultimately v2048i32 needs to be split into 32 v64i32 instructions. the only difference between 2 is if its orginally v2048i32 i want my registers assignment from REG_A set. if its v64i32 originally, then i want registers from set REG_B. How to accomplish
2009 Apr 07
6
[LLVMdev] Porting to System z
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 =================================================================== ---
2009 Dec 02
0
[LLVMdev] Adding multiples-of-8 integer types to MVT
Instead of putting the burden on the back-ends to implement special lowering code, why not implement code in the legalizer that would automatically sign extend them to the next largest power of 2 integer if the specific integer types were not supported. This would then remove the need of the back-ends to implement anything as LLVM would just generate extend the values to i32/i64 silently. Micah
2017 Jul 12
2
Using new types v32f32, v32f64 in llvm backend not possible
I would be very grateful if you specify whether there is some way to allocate registers (different order) / from different register sets to the same instruction based on the vector width/ no of iterations. I have tried several alternatives but could not succeed. Also I have asked this question many times but no one responds. Is there something wrong with this?? Kindly guide me. Thank You On
2013 Jun 23
0
[LLVMdev] Register Class assignment for integer and pointer types
Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is perhaps a bit different form yours,
2013 Jun 23
3
[LLVMdev] Register Class assignment for integer and pointer types
David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from
2009 Dec 03
0
[LLVMdev] Adding multiples-of-8 integer types to MVT
On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > Would there be any interest/opposition to extending the set of simple > integer types in MVT to include the missing multiples of 8 (up to 64 > bits)? That is: i24, i40, i48, i56? > > Adding the types to MVT (and ValueTypes.td) would allow LLVM to be > targeted to architectures that have registers and operations of these > sizes
2016 Dec 15
2
TableGen - Help to implement a form of gather/scatter operations for Mips MSA
Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from
2009 Dec 03
1
[LLVMdev] Adding multiples-of-8 integer types to MVT
On Wednesday, December 02, 2009 7:09 PM, Chris Lattner wrote: > > On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > > > Would there be any interest/opposition to extending the set > of simple > > integer types in MVT to include the missing multiples of 8 > (up to 64 > > bits)? That is: i24, i40, i48, i56? > > > > Adding the types to MVT (and
2009 Dec 02
11
[LLVMdev] Adding multiples-of-8 integer types to MVT
Would there be any interest/opposition to extending the set of simple integer types in MVT to include the missing multiples of 8 (up to 64 bits)? That is: i24, i40, i48, i56? Adding the types to MVT (and ValueTypes.td) would allow LLVM to be targeted to architectures that have registers and operations of these sizes (for example, a 24-bit DSP that I'd like to develop a back end for has 24-,
2013 Jun 21
0
[LLVMdev] Register Class assignment for integer and pointer types
We also have this problem, and have added iPTR types to the back end. Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...). Most of the changes are a bit ugly, and I'm loath to upstream them without
2017 Jul 28
0
Addressing TableGen's error "Ran out of lanemask bits" in order to use more than 32 subregisters per register
Hello. I come back to this older thread. As I've said before, I managed to patch the various files from the back end related to lanemask in order to support at most 1024 vector lanes. For this I am using a 1024-bit long lanemask of type uint1024_t from boost::multiprecision, instead of uint32_t. For this I changed the following LLVM source files:
2009 Aug 19
0
[LLVMdev] gcc4.4's -O2 is breaking include/llvm/CodeGen/ValueTypes.h
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)’: >
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode,
2009 Aug 18
2
[LLVMdev] gcc4.4's -O2 is breaking include/llvm/CodeGen/ValueTypes.h
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
2013 Jun 24
2
[LLVMdev] Register Class assignment for integer and pointer types
On Sun, Jun 23, 2013 at 04:57:44PM +0100, David Chisnall wrote: > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend