similar to: RegAlloc Q: spill when implicit-def physreg is also the output reg of instruction

Hi Quentin, MyInst is a custom instruction that has implicit-defs of fixed registers. The implicit-defs are seen at the end of Instruction Selection. I'd like to add a report, but I am working on an out-of-tree backend based on 7.0. I can try to help reduce the testcase down. Filed https://bugs.llvm.org/show_bug.cgi?id=41790 Regards, Kevin On 2019-05-07 3:45 p.m., Quentin Colombet wrote:

For example, if you have something like: .... vreg3 = LD operation vreg4 = vreg2 * vreg1 ... Where I would like vreg3 and vreg4 to map to the same physical register? Imagine that the second instruction has an implicit arithmetic operation tied to vreg 4 such that vreg4 is both an input and output and the initial value of vreg4 is loaded into vreg3, so such that vreg4 = vreg3. Is this possible

I want to add a set of "properties" to each instruction in my instruction set, and want to be able to query that in my machine-specific optimizations. My Insts.td file looks as follows : class InstProperty; def propX : InstProperty; def propY : InstProperty; def propZ : InstProperty; class myInst<..., list<InstProperty> props> : Instruction { ... ...

Manjunath, I asked this question recently, but instead of telling you to search the archive I'm going to take it as a chance to recall how to do it (because I'll do so anyway and even telling tablegen to use an enum for instructions is not as trivial to do as you might think : ) I wrote it up in the wiki at http://wiki.llvm.org/HowTo:_Add_arbitrary_properties_to_instructions Regards,

Evan, >A physical register cannot be live across the block. So it >must have a use in the block or it must be marked dead. From >your dump, it looks like the CCFLAGS defs are not being marked >dead. It's unclear where things went wrong, but you can step >through LiveVariables to debug this. Thanks for your response. I did quite some stepping through the llc passes, and it

A physical register cannot be live across the block. So it must have a use in the block or it must be marked dead. From your dump, it looks like the CCFLAGS defs are not being marked dead. It's unclear where things went wrong, but you can step through LiveVariables to debug this. Evan On Jan 9, 2009, at 2:50 AM, Christian Sayer wrote: > Hello, > > For my backend, I define and

Hello, For my backend, I define and use a CC register similiarly to the EFLAGS register in X86 (I call it CCFLAGS). But if I make all arithmetic/logic instructions affect it ('let Defs = [CCFLAGS] in...' in InstrInfo.td) I run into // The only case we should have a dead physreg here without a killing or // instruction where we know it's dead is if it is live-in to the function

How can I prevent some nodes from being combined in DAGCombine.cpp? Maybe what I want to do below doesn't follow the philosophy of LLVM, but I'd like to know if there is any way to avoid node from being combined. TargetLowering::PerformDAGCombine() is only called if DAGCombiner cannot combine a specific node. It seems that there is no chance to stop it from combining a node. I need the

Hello all! I was looking through the results of disassembling a heavily-used short function in the program I'm working on, and ended up wondering why LLVM was generating that assembly and what changes would be necessary to improve the code. I asked on #llvm, but it seems that the people with the necessary expertise weren't around. Here is a condensed version of the code:

On 02/27/2018 10:21 AM, Alex Wang via llvm-dev wrote: > Hello all! > > I was looking through the results of disassembling a heavily-used > short function > in the program I'm working on, and ended up wondering why LLVM was > generating > that assembly and what changes would be necessary to improve the code. > I asked > on #llvm, but it seems that the people with

Hello, I noticed the following interesting code sequence while compiling a piece of code with the backend I'm developing. Probably this issue is for Jakob, but anyways this is what I'm getting: STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) STDWPtrQRr <fi#13>, 0, %R23R22;

On Mon, 16 Apr 2007, David Greene wrote: >> Yep, this is the one I was thinking of. It is available online here: >> http://www.cs.rice.edu/~keith/LACSI/pldi02.pdf > > I was just looking at this today. One thing that strikes me about > all these papers I've read on the topic is that no one seems to > consider the interaction of coalescing with spilling. By definition

It seems to me that LLVM sub-register is not for the following hardware architecture. All instructions of a hardware are vector instructions. All registers contains 4 32-bit FP sub-registers. They are called r0.x, r0.y, r0.z, r0.w. Most instructions write more than one elements in this way: mul r0.xyw, r1, r2 add r0.z, r3, r4 sub r5, r0, r1 Notice that the four elements of r0 are written

Hello, I am having some trouble matching patterns in targetinstructioninfo.td file with the CodeGen expectation. Could anybody please help? Here is the example: I want to emit instruction for adding 2 different kind of oprands. Basically i want to mix register types when I define the instruction for add,sub etc I define the instruction TargetInstruction.td as follows: class MyInst <opcode

On Jan 27, 2012, at 10:20 AM, Borja Ferrer wrote: > Hello, > > I noticed the following interesting code sequence while compiling a piece of code with the backend I'm developing. Probably this issue is for Jakob, but anyways this is what I'm getting: > > STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) > STDWPtrQRr <fi#12>, 0, %R25R24;

This sounds great! I've been bitten in the past by trying to use a single class for multiple types. Would it make sense to extend this to all DAG patterns? If I have an instruction def: def ANDN64 : MyInst<(outs Reg64:$d), (ins Reg64:$a, Reg64:$b), "and.64 $d, $a, $b", [(set Reg64:$d, (and (not (Reg64:$a, Reg64:$b))))]>; would I now be able to write: def ANDN64 :

Hello, I am new to LLVM and I am not sure whether I am writing to the right distribution list or not. Please let me know if this is not the right distribution list. Question: - I am having hard time lowering ADD instructions for different purposes. Basically, I want to have different machine instruction for pointer addition vs scalar addition. I am having hard time mapping LLVM add to my machine

I am hitting this assert in LLVM 2.5: /// spillPhysRegAroundRegDefsUses - Spill the specified physical register /// around all defs and uses of the specified interval. void LiveIntervals::spillPhysRegAroundRegDefsUses(const LiveInterval &li, unsigned PhysReg, VirtRegMap &vrm) { unsigned SpillReg = getRepresentativeReg(PhysReg); for (const

Hi Jacob, thank you for your reply. Your suggestion works! But instead of using the Pat<>, I am using def MOVE_ADDR : MYInst<(outs Int32Regs:$dst), (ins i32mem:$a), "move $dst, $a;", [(set Int32Regs:$dst, (Wrapper tglobaladdr:$a))]>; I don't quite understand what the semantics of Pat in general. Could you please explain what

On May 9, 2012, at 4:27 AM, Anton Korobeynikov wrote: > Hello Jonas, > >> I wonder, what would be the best solution for instructions that require >> operands in a particular register, and even gives the result in a particular >> register? > You need to custom select such instruction. See e.g. div / idiv on x86 > as an example. That's often easiest, yes;