search for: addregisterclass

...all places that used XXXRegisterClass should be changed to &XXXRegisterClass. I already did the conversion for all targets in the tree so this is a notice to out of tree targets. One of the most common place you might find this is setting up register classes in TargetLowering. For example, addRegisterClass(MVT::i8, X86::GR8RegisterClass); addRegisterClass(MVT::i16, X86::GR16RegisterClass); addRegisterClass(MVT::i32, X86::GR32RegisterClass); These should be changed to addRegisterClass(MVT::i8, &X86::GR8RegClass); addRegisterClass(MVT::i16, &X86::GR16RegClass); addRegisterClass(MVT:...

...es. For example: def SReg_64 : RegisterClass<"AMDGPU", [i64], 64, (add SGPR_64, VCC, EXEC)>; def VReg_64 : RegisterClass<"AMDGPU", [i64], 64, (add VGPR_64)>; What criteria should I use to decide which register class to associate with each type using TargetLowering::addRegisterClass() ? Thanks, Tom

I'm having some troubles implementing vector support to our custom backend It seems that llvm cannot emulate shuffle with extracts, inserts and builds? I've enabled vector registers with addRegisterClass(MVT::v2i32, TCE::V2I32RegsRegisterClass); addRegisterClass(MVT::v2f32, TCE::V2F32RegsRegisterClass); and created patterns for most vector instructions, including insert, extract and build. I've tried to say setOperationAction(ISD::VECTOR_SHUFFLE, MVT::v2i32, Expand); setOperationAction(ISD:...

Hi Matt, I did call addRegisterClass in TargetLowering for all the possible types in the register. And for typecasting instructions (i32 to i64), it works. Any other possiblilities? On Thu, Jul 2, 2015 at 6:12 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 07/02/2015 05:56 PM, Xiaochu Liu wrote: > > Hi e...

...::LOAD, MVT::f32, Promote); > > AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); > > > > Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. > > What is going on? > > > > I still have the following:(but I think that's fine) > > addRegisterClass(MVT::f32, &Opus::GR32RegClass); > > Have you specified a register class for MVT::i32? If not, I think that > may be your problem. > > -Tom > Yes I have, f32 and i32 map to the same register class: addRegisterClass(MVT::i32, &Opus::GR32RegClass); -------------- next par...

...otedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote); AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. What is going on? I still have the following:(but I think that's fine) addRegisterClass(MVT::f32, &Opus::GR32RegClass); Thanks. (My LLVM is ~3 months old) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130805/90d2ec3b/attachment.html>

Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type legalization will stop expanding i64 operations because i64 is now a legal type. Then we will probably have to write lots of code to custom-lower unsupported 64-bit operations during legalization. Note that mips3...

Are you marking i16 a legal type? In XXISelLowering.cpp, you should assign it a register class. e.g. addRegisterClass(MVT::i16, XX::i16RegisterClass) Evan On Feb 2, 2009, at 12:19 PM, Villmow, Micah wrote: > It seems that LLVM is converting all the 16 bit ints into 32 bit > ints. Is there a way I can tell LLVM that 16 bit ints are valid and > legal and not to do any conversions on them? > >...

Hi everyone, I tried to declare multiple data type [i64, i32, v2i32] for a 64 bit register class GPR. It works OK but I have one problem that is hard to find. When I tried to map a load instruction of a v2i32 type (LOAD v2i32:$dst) to load GPR, it always generate two LOAD i32 instead of one LOAD v2i32. Any folds understand how this works? Xiaochu -------------- next part -------------- An HTML

...2); > setOperationAction(ISD::LOAD, MVT::f32, Promote); > AddPromotedToType(ISD::LOAD, MVT::f32, MVT::i32); > > Now SelectionDAGLegalize::LegalizeDAG() get stuck into an infinite loop. > What is going on? > > I still have the following:(but I think that's fine) > addRegisterClass(MVT::f32, &Opus::GR32RegClass); Have you specified a register class for MVT::i32? If not, I think that may be your problem. -Tom

...ps16ISelLowering.cpp +++ b/lib/Target/Mips/Mips16ISelLowering.cpp @@ -39,6 +39,14 @@ namespace { Mips16TargetLowering::Mips16TargetLowering(MipsTargetMachine &TM) : MipsTargetLowering(TM) { + // + // set up as if mips32 and then revert so we can test the mechanism + // for switching + addRegisterClass(MVT::i32, &Mips::CPURegsRegClass); + addRegisterClass(MVT::f32, &Mips::FGR32RegClass); + computeRegisterProperties(); + clearRegisterClasses(); + // Set up the register classes addRegisterClass(MVT::i32, &Mips::CPU16RegsRegClass);

It seems that LLVM is converting all the 16 bit ints into 32 bit ints. Is there a way I can tell LLVM that 16 bit ints are valid and legal and not to do any conversions on them? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part

Thanks. I'm gonna try tomorrow and let you know. On Thu, Jul 2, 2015 at 6:51 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 07/02/2015 06:41 PM, Xiaochu Liu wrote: > > Hi Matt, > > > > I did call addRegisterClass in TargetLowering for all the possible > > types in the register. And for typecasting instructions (i32 to i64), > > it works. Any other possiblilities? > Try looking at the output of -debug-only=isel and see where the load is > getting split up. The load isn't reaching instru...

...gisters. > In our processor, addresses (i.e. pointers) must be assigned to a specific kind of registers before it can be used for memory access, which is the common part between yours and ours. Here are 2 possible solutions for our problem: 1. constrain instruction selection. 1.1 use "addRegisterClass(MVT::iPTR, XXX::PTRRegClass);" to bind pointers and their register class. 1.2 add a pass to transform ISelDAG before instruction selection. Since we can determine from opcodes whether an operation can only take address registers as its input operands, we replace i32 with iPTR if so, and inse...

Hi Akira, Micah, On 05/09/2012 21:44, Akira Hatanaka wrote: > Micah, > > Do you mean we should make GPR64 available to register allocator by > calling addRegisterClass? > > addRegisterClass(MVT::i64, &GPR64RegClass) I have a related question to this thread. Does the RA use target lowering information? Because if it doesn't, you don't need to register your i64 reg class. Ivan > > If we add register class GPR64, type legalization will st...

...loaded effective address? Again, thank you for your help! Best, Miguel From: Sebastien Le Duc [mailto:sleduc at kalray.eu] Sent: February 06, 2020 4:27 PM To: Miguel Inigo J. Manalac Subject: RE: [llvm-dev] LLVM Backend Legalize Phase I think you can make the 32bit and 64bit types legal (using addRegisterClass) and use setOperationAction(Expand) for all the operations for which you don’t have native support. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Miguel Inigo J. Manalac via llvm-dev Sent: Thursday, February 6, 2020 2:27 AM To: llvm-dev at lists.llvm.org Subject: [llvm-de...

From: Akira Hatanaka [mailto:ahatanak at gmail.com] Sent: Wednesday, September 05, 2012 12:44 PM To: Villmow, Micah Cc: reed kotler; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] 64 bit special purpose registers Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type legalization will stop expanding i64 operations because i64 is now a legal type. [Villmow, Micah] You'll have to set everything that you don't support to 'Expand' and everything you do support int...

...consecutive registers? On Thu, Sep 6, 2012 at 5:06 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Akira, Micah, > > > On 05/09/2012 21:44, Akira Hatanaka wrote: > > Micah, > > Do you mean we should make GPR64 available to register allocator by > calling addRegisterClass? > > addRegisterClass(MVT::i64, &GPR64RegClass) > > > I have a related question to this thread. Does the RA use target lowering > information? > Because if it doesn't, you don't need to register your i64 reg class. > > Ivan > > > > If we add regist...

...'m gonna try tomorrow and let you know. >> >> On Thu, Jul 2, 2015 at 6:51 PM Matt Arsenault <Matthew.Arsenault at amd.com> >> wrote: >> >>> On 07/02/2015 06:41 PM, Xiaochu Liu wrote: >>> > Hi Matt, >>> > >>> > I did call addRegisterClass in TargetLowering for all the possible >>> > types in the register. And for typecasting instructions (i32 to i64), >>> > it works. Any other possiblilities? >>> Try looking at the output of -debug-only=isel and see where the load is >>> getting split up. Th...

Thanks for the reply Jakob, good to know that my assumption that LLVM would split regs into smaller subregs is confirmed to be too optimistic. It would be nice if this case could be handled by LLVM, basically trying to split regs and see if patterns match with the splitted regs before giving an error. About the transformation you mentioned in the selection DAG phase, that was my initial question,