similar to: [LLVMdev] (implicit <reg>) vs. Defs = [<reg>] in InstrInfo.td

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

Hello, The ScheduleDAGInstrs::buildSchedGraph() function creates def/uses lists by iterating over all instruction operands and calls addPhysRegDeps() if used post-RA (line ~770 ff.). If an operand is a def, the uses of that registers are cleared (ScheduleDAGInstrs.cpp:333: Uses.eraseAll(Reg); ). As a consequence, if an instruction has an explicit use of a register and an implicit def of the

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:

Hi LLVM, I ran into a case where RegAlloc would insert a spill across instruction that had same register for output operand and implicit-def. The effect this had was that spill code would immediately overwrite the output result. Is this the expected result of setting up MyInst this way? In other words, does RegAlloc know to not insert spill in case it sees that output reg is same as one of

On Sat, 14 Oct 2006, Roman Levenstein wrote: >> On Sat, 14 Oct 2006, Roman Levenstein wrote: >>> Is it possible to dynamically define implicit defs for some >>> instructions? >> >> Yes! This is what explicit operands are :). Specifically, if you >> want to >> vary on a per-opcode basis what registers are used/def'd by the >> instruction,

Hi, Is it possible to dynamically define implicit defs for some instructions? Concretely, I'd like to define a register for a return value of a call in a dynamic way, instead of using current static approach looking like: let Defs = [R0] in def CALLimm : I<...>; The reason for this wish is that some of the calling conventions on my target use different sets of physical registers

On Sat, 14 Oct 2006, Roman Levenstein wrote: > Is it possible to dynamically define implicit defs for some > instructions? Yes! This is what explicit operands are :). Specifically, if you want to vary on a per-opcode basis what registers are used/def'd by the instruction, you can just add those registers as explicit use/def operands in the machine instruction with the physical

Hi Tom, Thanks a lot for your explanations, now it makes a lot more sense ;) I had a slightly closer look at the R600 packetizer, and the issue is that the third LSHL instruction has both an implicit use and *afterwards* an implicit def of T1_XYZW. The latter def causes the current ScheduleDAGInstrs implementation to ignore the implicit use, thus the ScheduleDAG only contains an

Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers

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

Hi, I'm trying to add a target-specific builtin to clang and llvm. I was able to do that for many different "regular" instructions, however I encountered some issues with one specific. The instruction is syscall, which should force the compiler to act the same way as with regular calls (save registers, return address etc), except that this instruction takes just the syscall number as

The best fix is to teach this scheduler how to deal with these dependencies. :-) If you just want a check, I think it's easier to just check register class's copy cost. -1 means it's extremely expensive to copy registers in the particular register class. Evan On Feb 6, 2009, at 2:22 AM, Christian Sayer wrote: > Hi, > > I just switched to the 2.5 release branch and

I am adding a new target to LLVM (a DSP processor). Resulting code size on an embedded system is as important as code efficiency. So my first question is: How to introduce code size criteria in the instruction selection ? Is there any scheme already in place for that purpose ? My second question is related to my target. On this target, arithmetic and bitwise instructions that modify the flag

Hi, I just switched to the 2.5 release branch and noticed that llc runs into the following assert in ScheduleDAGList::ScheduleNodeTopDown() using our custom backend: assert(!I->isAssignedRegDep() && "The list-td scheduler doesn't yet support physreg dependencies!"); It turns out that the register dependency concerns the condition code register which is

Hi all, I would like to know if XXXInstrInfo.td or other td files should be the right place to specify Src Reg and Dest Reg in one instruction can't be the same. If so, could you give an example on that? Thanks! Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage:

Hi Wei-Ren, I don't think you can model it with Constraints in td files. You may try to put a regalloc hint in src and dst operands of the instructions you are interested. See getRawAllocationOrder(), ResolveRegAllocHint() and UpdateRegAllocHint() hooks in TargetRegisterInfo. ARM has good examples on how to implements them. Ivan On 13/07/2012 09:28, 陳韋任 (Wei-Ren Chen) wrote: > Hi

I think we can get rid of the TSFlagsFields and TSFlagsShifts hack in the InstrInfo TableGen class now. This seems to work just fine: class Instruction { bits<32> TSFlags; } class Domain<bits<2> val> { bits<2> Value = val; } def GenericDomain : Domain<0>; def SSEPackedInt : Domain<1>; def SSEPackedSingle : Domain<2>; def SSEPackedDouble :

On Jun 4, 2010, at 3:05 AM, Sylvere Teissier wrote: > > In my target the CALL instruction change the link Register %LR > In the target InstrInfo.td I have "Defs=[LR]" on the CALL instruction > definition to handle that. So your CALL instructions are clobbering your callee-saved registers, eh? ;-) > It works well with others registers allocators: when there is a call

I'm working on an out-of-tree target and am having some problems with rematerialization and spilling. The target's load and store instructions affect the condition code register (CCR). Describing this in the InstrInfo.td file using Defs = [CCR] certainly prevents spills and fills from being inserted where they might clobber CCR but it also prevents the load instruction from being