similar to: [LLVMdev] initialize register attributes in instruction definition

On Jul 31, 2014, at 7:23 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Jul 31, 2014 at 06:41:06PM -0400, kewuzhang wrote: >> Hi All, >> >> Is it possible to initialize(set up) register attributes when we define an instruction? >> >> like >> >> if a register is defined like this: >> >> " class

Is there any reason why we can't generate HWEncoding based decoders for registers for mc disassemblers? This is a concept patch to explore wether it'd work, and for my target, it does the right thing. I have one case where I have to shift a field over 2 bits, but I handle that in the glue. If I had a HWEncoding encoding on a per register class basis, I could have made it work without

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

On Feb 10, 2017, at 6:58 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I suspect that, for many targets, this is possible. It is just that no one has done the work to make this happen. Ah, ok, just surprising to me then, as I find it more palatable to write the generator than to produce the list. > So that we're on the same page, I believe you're talking about getting rid of

Is it possible to define lookup tables as a list in tablegen, to map one value to another? Here's the template I was working on: ========================================= class LookupTable { list<int> mapping = [0, 8, 16, 24, 32]; } def LUT : LookupTable; class MyRegister<name, index> : Register<name> { let HWEncoding = LUT.mapping[index]; int otherVal = index;

Dear all, in my TestRegisterInfo.td file, I defined a register like this: class TestReg<bits<6> enc, string name> : Register<name> { let HWEncoding{5-0} = enc; let Namespace = "TEST"; } def D0 : TestReg<0x01, "d0">, DwarfRegNum<[1]>; but when I compile, the result I have in TestGenAsmMatcher.inc is this: case 'd': // 7

Hi all, is it possible in TableGen to set value to instruction bits based on the operands? In other words, parsing the instruction at the TableGen level. for instance: "add $Rd, $Rn, $imm" I want to have something like this: *Inst{8} = ($Rn == Test::A0) 1 : 0;* Is there any way to do that in TableGen? If not is there any example in the provided example codes? Cheers, ES

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

Hello Krzysztof, The R_CASS definition is as follows: class R_CASS<string n, bits<16> Enc, list<Register> subregs = []> : Register<n> { let Namespace = "X86"; let HWEncoding = Enc; let SubRegs = subregs; } On Thu, Jul 20, 2017 at 4:14 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > I tried reproducing the problem, but the file

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

On 9/17/2015 8:30 AM, Sky Flyer wrote: > Hi Krzysztof, > > Thanks for your reply. I wanted to assign the hardware encoding to the > Instruction bits like the link below: > > https://groups.google.com/d/msg/llvm-dev/BfUmfIWYRM8/6JGXQf1gCQAJ > > but, at the end, what is assigned to the Inst is, I suppose, the > register ID not the encoding! > > to be more clear, I do

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#

On 9/17/2015 7:04 AM, Sky Flyer via llvm-dev wrote: > It seems like d0 is always 14! > I check it with ARMGenAsmMatcher.inc it was the same! > How is it possible? because it should give the same register value that > matches the underlying platform not any autogenerated value!? The returned number is the register id as defined in <YourTarget>GenRegisterInfo.inc. These numbers