similar to: [LLVMdev] Breaking changes in *RegisterInfo.td regarding SubRegIndex

Hello Everyone, I am trying to make a new LLVM backend target for Intel GPU. I would start from targeting OpenCL language first. But I am not quite familiar with LLVM backend infrastructure. I have some problem on describing the RegisterInfo. Intel GPU launches lots of hardware threads to do GPGPU workload. Each hardware thread has 128 registers(r0-r127), with each one of size 32 byte. Each

Yes, the arch is just as you said, something like AMD GPU, but Intel GPU don't have separate register file for 'scalar/vector'. In fact my idea of defining the register tuples was borrowed from SIRegisterInfo.td in AMD GPU. But seems that AMD GPU mainly support i32/i64 register type, while Intel GPU also support byte/short register type. So I have to start defining the registers from

Folks, Please confirm or correct the following assertions: In Target.td one of the data member fields for class Register is list<string> AltNames. If this is for alternate names for a given register (in Mips $28 and $gp are the same) it would be quite useful for the llvm-mc assembler which has to handle cases where there are multiple names for the same register. A quick recursive grep

Hi I'm returning to my MC6809 back-end from a health-related hiatus. The assembler is tantalisingly close, but I've got some parsing and matching problems. The register set; these overlap in annoying ways, for instance, two instructions TFR and EXG each have a single opcode, and the post-byte specifies which registers are to be involved, but the registers can be 8- or 16-bit, and 2 of

Hi Escha, Great to have your comment! Do you have any specific reason for not doing like this? I am not sure whether I understand your point correctly. For "just model one thread", do you mean "only considering ONE of the 8/16 working lanes that running in lock-step way"?? For my case, may be something like I only need to define r0~r127 as register for i32 register (each r#

If no i64 reg classes are registered, then type-legalization will expand a 32b x 32b = 64b multiply node into a 32-bit mult node with two i32 results (for example, SMUL_LOHI). The problem is that there isn't an easy way to have RA assign two consecutive hi/lo registers to the two i32 registers, once the 64-bit result is split into two 32-bit results. Is there a constraint I can use (something

Hello Jeff, you're the first one to reply to my question :) I got a bit confused with the fact you said that the subregister class is larger than the superregister class. As far as i understood or what i tried to do with my code is to define a register pair composed of two 8 bit registers the way i described in my previous message. So R1R0 in WDREGS is directly mapped into R0 and R1 of GPR8.

On Tue, Sep 6, 2011 at 9:34 PM, Alexandru Dura <alexdura at gmail.com> wrote: > Hi everyone, > > I found some peculiar behavior of TableGen when generating > [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in > this file, leading to a compilation error. Hi, What do you mean "overlapped register"? > I think this is because in

I'm working on a target based on the MIPS target, and when I copy f64 values into 32 bit registers for calling functions, I need the operation to work on a of 32 bit registers (because the language I'm translating to isn't actually mips). I've been looking at how to do this, but I haven't been able to figure it out. Since the Mips target code is still really close to mine,

I have made changes in 3 files: LaneBitmask.h, codegenregisters.cpp and miparser.cpp. files are attached here. Now i am getting following errors. which means registerinfo.inc file is not generated successfully. /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24: error: no member named 'XMM8' in namespace 'llvm::X86' if ((RegNo >= X86::XMM8 && RegNo <=

Hi everyone, I found some peculiar behavior of TableGen when generating [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in this file, leading to a compilation error. I think this is because in RegisterInfoEmitter.cpp, RegisterAliases are declared as "std::map<Record*, std::set<Record*>, LessRecord>" and a requirement for std::map is that the

Ryan, I don't think I fully understand the problem you described, but please see the comments below. Hope this helps you solve the problem. On Sat, Oct 6, 2012 at 3:18 PM, ryan baird <ryanrbaird at gmail.com> wrote: > I'm working on a target based on the MIPS target, and when I copy f64 > values into 32 bit registers for calling functions, I need the operation to > work

Hi, Jiong, Thanks for the patch! It is a great start to support 32bit register in BPF. In the past, I have studied a little bit to see whether 32bit register support may reduce the number of unnecessary shifts on x86_64 and improve the performance. Looking through a few bpf programs and it looks like the opportunity is not great, but still nice to have if we have this capability. As you

On Aug 31, 2010, at 1:06 PM, Borja Ferrer wrote: > Incase i wasnt clear enough i'll expose a simple example using the common known x86 arch. > AX is composed by AL and AH (AX and AH are subregs of AX), now assume x86 can only add regs of 8 bits, so if a i16 number is stored in AX it should get splitted into AL and AH so that the 8 bit addition pattern is matched. > > If this is

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote: > Hi, > > I think I've found a bug in this method. > > I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. > > For the def-operand, with a subregindex, an implicit-use operand was added with this code: > >

Hi, I think I've found a bug in this method. I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg,

> On Feb 27, 2015, at 2:15 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > > On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >>> Which brings us to my fallback proposal: what about disabling the >>> pass on darwin

This can be done by declaring a register class with these registers and only using that register class as an operand in the instructions where it is legal. You then set as sub registers what you want to represent as the hi and lo registers for those 64bit registers. So something like this: def lo_comp : SubRegIndex; def hi_comp : SubRegIndex; def R1 : Register<1>; def R2 :

I may get one or two in the next month, but not more than that. Focused on the pass manager for now. If none get there first, I'll eventually circle back though, so they won't rot forever. On Jan 30, 2015 11:21 AM, "Ahmed Bougacha" <ahmed.bougacha at gmail.com> wrote: > I filed a couple more, in case they're actually different issues: > -

Yes, I'm saying that the implicit-def operand that was added in this case ended up as #4, out of 6, when the operands list was reallocated in addOperand(). If addOperand was rewritten, I think it's best not to add my fix for ProcessUses(), as I wrote earlier. Jonas Subject: Re: [LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses() From: stoklund at 2pi.dk Date: Wed, 12 Oct 2011