similar to: [LLVMdev] Question about PseudoInstExpansion

Hi Hal, Thanks for your reply and it is helpful! I have a quick question: When I use BuildMI to build instructions in this case, do I have to add all three of the register operands explicitly (operand 0 and 1 are the same)? Thanks, Xiaochu On Tue, Nov 24, 2015 at 3:14 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Xiaochu Liu via

Hi all, I'm trying to solve a problem that we have in implementation of the assembler for Mips platform in llvm. Mips has some pseudo instructions that, depending on the arguments can be emitted as one or more real instructions by the assembler. For example load immediate instruction can have multiple expansions depending on a size of immediate operand: This expansion is for 0 ≤ j ≤ 65535. li

Hi Vladimir, The pass you refer to isn't used by the assembler at all. That's strictly a compiler codegen thing. The assembler equivalents are expressed via InstAlias constructions. Again, though, those are for a single output instruction, so you need something more. Sprecifically, you can handle assembly pseudo-instructions in C++ code. Something like the ARM assembler's

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

Hi Jim, thank you for the quick response. I have used InstAlias in some cases, but these are really simple pseudo instructions where the pseudo instruction is more like a special case of existing one, like using fixed operand or simply a more human understandable way of presenting an operation. I know that there are predicates available to improve matching, but can InstAlias use conditions to

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

Dear there, I'm developing an instruction layout like: opcode | rd| ts and its semantics is: rd= rd opcode rs But when I describe it in td file like this: class R<bits<5> Op, string OpcodeStr, list<dag> Pattern> : InstV<(outs GPR:$rd), (ins GPR:$rd, GPR:$rs), !strconcat(OpcodeStr, "\t$rd, $rs"), Pattern> { bits<5> rd; bits<6> rs; let

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

It seems like it might be a legitimate complaint from the register allocator. It's trying to get an accumulator (not a general purpose register) and the accumulator is 64 bit. It's using a part of the Mips backend that I have not worked in so I have to research this a bit. The multiply instruction is a pseudo multiply in the mips backend and it needs the accumulator which a special

Short version: If the integrated assembler accepted assembly strings as input, more targets could take advantage of integrated assembly. The longer version: For a given assembly statement, my out-of-tree target has complex instruction selection logic -- more so than the in-tree targets. This target uses variable length instructions and a laborious hierarchy of tblgen AsmOperands to do the job.

> I've disassembled the failing MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 and compared it to > the one from the LLVM 3.6.0 test runs. There's nothing obvious. We've removed some useless > 'addiu $sp,$sp,0', eliminated two (seemingly redundant) sign extends, and the addresses of > functions+data has changed slightly. I've investigated further and I'm

Hi all, Can someone please explain me how to use REG_SEQUENCE in tablegen? The arch i'm writing backend for has 32-bit regs, and it has a couple of 64-bit load/store instructions which use two neighboring regs at once, which i'm trying to employ using virtual regs with subs. For example, it I want to move one 64-bit virtual reg to another, I'm trying to use the following pattern:

This is a bit premature to be considered a code review, but given how unfamiliar I am with SelectionDAG (& that I'm seeing somewhat more 'interesting' results compared to my change to FastISel) I wanted to get a bit of feedback to see if I was on the right track or had missed any obvious cases. I've attached my patch in progress (including a modification to the existing test

I try to define a register class def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] to simulate even/odd pair of GPR32 register. Actually, I just use GPR64 as a temporary register. My CPU just support i32 Integer type directly. I use FDR to save f64. def FDR : RegisterClass<"mytarget", [f64], 64,[FD0, FD1, ....] When I move f64 to even/odd pair register, I

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

> On Nov 11, 2017, at 11:03 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/11/2017 12:44 PM, Amara Emerson wrote: >> >>> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com <mailto:proaditya at gmail.com>> wrote: >>>> >>>> The current DAGCombine, being constructed on top of

On 11/11/2017 12:44 PM, Amara Emerson wrote: > >> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com >> <mailto:proaditya at gmail.com>> wrote: >>> >>> The current DAGCombine, being constructed on top of SDAG, has a kind >>> of built-in CSE and automatic DCE. How will things change, if >>> they'll change, in

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

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

Preamble -------- While working on an IR-level optimisation completely unrelated to register allocation I happened to trigger some really strange register allocator behaviour causing a large regression in bzip2 in spec2006. I've been trying to fix that regression before getting the optimisation patch committed, because I don't want to regress spec2006, but I'm basically fumbling in