similar to: Mischeduler: Unknown reason for peak register pressure increase

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.

I'm trying to compute and print a weighted spill cost based upon the execution frequency of the basic block where the spill is inserted. My goal is to analyse what effect scheduling changes have on the sum of this weighted spill cost in some benchmarks. I've experimented doing this directly before a spill is inserted in InlineSpiller.cpp using MBFI.getBlockFreq()

Hi, Regarding the mischeduler, I wonder // For loops that are acyclic path limited, aggressively schedule for // latency. This can result in very long dependence chains scheduled in // sequence, so once every cycle (when CurrMOps == 0), switch to normal // heuristics. if (Rem.IsAcyclicLatencyLimited && !Zone->getCurrMOps() && tryLatency(TryCand, Cand, *Zone))

Hi, I am looking at the Hexagon MI Scheduling and trying to adapt it to my target. As far as I can see, Hexagon does not bundle the VLIW-bundles by calling bundleWithPred() on MIs of the completed cycle. First of all, why is this not done? SlotIndexes seems to have at least some support for this, by calling getBundleStart() for each MI that is looked up. A follow up question is then, how would

Hi Quentin, Thanks for the reply! However, we are not using any profiling-based compilation in our current work. We are assuming that, if PGO is disabled, the register allocator (and any other pass that needs basic block frequency info) will be basing its decisions on some kind of *static" basic block frequency info that are based on some compile-time heuristics and at least capture loop

> > Of course, you want to duplicate as little of the generic scheduling logic > as you can. So I think the challenge is how to expose the > generic scheduler's functionality as a base class or composition of > utilities so that defining your strategy doesn't require too much > copy-paste. ​Isn't GCNMaxOccupancySchedStrategy [1] already an example on using

Hi, I have been experimenting for a while with tryCandidate() method of the pre-RA mischeduler. I have by chance found some parameters that give quite good results on benchmarks on SystemZ (on average 1% improvement, some improvements of several percent and very little regressions). Basically, I add a "latency heuristic boost" just above processor resources checking:

Hello, While tuning the MIScheduler for my target, I discovered a code that unnecessarily restricts the scheduler. I think this is a bug, but I would appreciate a second opinion. In file ScheduleDAGInstrs.cpp, the function MIsNeedChainEdge determines whether two MachineInstrs are ordered by a memory dependence. It first runs through the standard criteria (Do both instructions access memory?

I have a question: In the pattern below from X86 def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), "inc{b}\tdst", [(set GR8:$dst, (add GR8:$src, 1))]>; Since we are emitting only "inc $dst", What makes sure that the $src and $dst are same register? - Sanjiv

sanjiv gupta wrote: > I have a question: > In the pattern below from X86 > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > "inc{b}\tdst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Since we are emitting only "inc $dst", > What makes sure that the $src and $dst are same register? > > - Sanjiv It's enclosed

I have some instructions that use a register as both an input and as the output. Is there a way to specify this constraint in the InstrInfo.td or will this have to be custom selected/lowered? Thanks -- Christopher Lamb christopher.lamb at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

> On Aug 30, 2017, at 1:43 PM, Matthias Braun <matze at braunis.de> wrote: > > That means you cannot use the code from RegisterPressure.{cpp|h} to compute this. The other liveness analysis we have in llvm codegen is LiveIntervals (LiveItnervalAnalysis) which gives you a list of liveness segments of a given vreg (the same representation is used in most linear scan allocators even

Hello. I write backend for Z80 cpu and I have some trouble with lowering load/store nodes to different machine opcodes. Some target instructions work with specified registers (not all registers in RegisterClass). Often it's one or two registers. I don't understand how use ComplexPattern in this case. But if I don't use ComplexPattern I'll have other problems - not all

Hi, I am wondering how to specify the selection DAG patterns for instructions that use accumulator. For example multiply-accumulate instruction with one destination operand and two source operands: mac $dst, $src1, $src2 ;; $dst += $src1*$src2 Seems that it has a cycle in the pattern. So how do I specify it in the DAG? There are a few instructions in the ARM backend like this one, but the

Hello all, Is there an easy way to get the human-readable opcode mnemonic (e.g., "MOV32ri64", "CMP32ri8", "JLE_1") for a MachineInstr? I am writing a backend analysis pass for security research, where the idea is for a researcher to examine the output of my pass and identify instructions from it for use in an attack. Right now I'm representing unique

I see in the x86 InstInfo.td the following for the INC instructions: def INC8r : I<0xFE, MRM0r, (ops GR8 :$dst, GR8 :$src), "inc{b} $dst", [(set GR8:$dst, (add GR8:$src, 1))]>; Which seem to have the same restriction that I'm trying to implement, but I don't understand how this ensures that $src and $dst are the same register. -- Christopher Lamb

On Thu, 1 Mar 2007, Christopher Lamb wrote: > I see in the x86 InstInfo.td the following for the INC instructions: > > def INC8r : I<0xFE, MRM0r, (ops GR8 :$dst, GR8 :$src), "inc{b} $dst", > [(set GR8:$dst, (add GR8:$src, 1))]>; > > Which seem to have the same restriction that I'm trying to implement, > but I don't understand how this

On Tue, 2008-09-23 at 13:33 +0100, Richard Osborne wrote: > sanjiv gupta wrote: > > I have a question: > > In the pattern below from X86 > > > > def INC8r : I<0xFE, MRM0r, (outs GR8 :$dst), (ins GR8 :$src), > > "inc{b}\tdst", > > [(set GR8:$dst, (add GR8:$src, 1))]>; > > > > Since we are emitting only "inc $dst",

Hi, This patch fixes outs/ins of MOV16mr instruction of X86. Thanks. diff --git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td index e9a0431..f5b2064 100644 --- a/lib/Target/X86/X86InstrInfo.td +++ b/lib/Target/X86/X86InstrInfo.td @@ -1412,7 +1412,7 @@ let SchedRW = [WriteStore] in { def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src),

On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote: > Hi, Bill and Jakob. > > I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction? > > I also don't