search for: instregex

...lines presented below, which are mapping the SchedReadWrite to, for example, the ANDri instruction. // ===---------------------------------------------------------------------===// // Subtarget-specific overrides. Map opcodes to list of SchedReadWrite types. // def : InstRW< [WriteALU], (instregex "ANDri", "ORRri", "EORri", "BICri", "ANDrr", "ORRrr", "EORrr", "BICrr")>; This same instruction is defined in the ARMInstrInfo.td as inheriting from AsI1_bin_irs (shown below) which, in turn, assoc...

...`` def A57WriteFPVMAD : SchedWriteRes<[A57UnitV]> { let Latency = 9; } def A57WriteFPVMAQ : SchedWriteRes<[A57UnitV, A57UnitV]> { let Latency = 10; } def A57ReadFPVMA5 : SchedReadAdvance<5, [A57WriteFPVMAD, A57WriteFPVMAQ]>; def : InstRW<[A57WriteFPVMAD, A57ReadFPVMA5], (instregex "^FML[AS](v2f32|v1i32|v2i32|v1i64)")>; def : InstRW<[A57WriteFPVMAQ, A57ReadFPVMA5], (instregex "^FML[AS](v4f32|v2f64|v4i32|v2i64)")>; ``` In this code, an 128bit ASIMD FP multiply accumulate(FMLA/FMLS Q-form) requires two `A57UnitV`s, meaning that two clock cycles...

I ran into an interesting problem when helping to land a scheduler .td file that my colleague had written. The problem that came up was that a multiply/add pair was not combined into an madd, but just for our CPU. Upon digging into it, the problem turned out to be that '(instregex "^SUB" ...' was matching "SUBREG_TO_REG" and incorrectly increasing the schedule length. I removed the overly aggressive match, but I noticed that there were lots of instructions that matched multiple regex patterns in InstegexOp::apply in utils/TableGen/CodeGenSchedule. I m...

Hi list, Is it possible to simulate load to store forwarding on aarch64 with MI scheduling model on AArch64? For instance $x0 data latency in the example below should be 1 cycle ldr $x0, [$x1] str $x0, [$x2] But it should be 4 cycles if we have another instruction: ldr $x0, [$x1] add $x0, $x0, 4 For ALU instructions it’s possible to use either ReadAdvance or SchedReadAdvance, but I don’t see

...the ReadAdr line in your subtarget to an override: def : ReadAdvance<ReadAdr, 3, [WriteLD]> Or instead you can just add a rule in your subtarget listing the opcodes or using a regex, and using the ReadAdr resource that you defined in the same file. def : InstRW<[WriteST, ReadAdr], (instregex "ST(someregex)$")>; Being careful about store-pair and vector stores. Then you always want to debug your target’s llvm-tblgen command by adding a flag -debug-only=subtarget-emitter And even trace the schedule for some simple cases with -debug-only=machine-scheduler I haven't ac...

I'm sure the x86 scheduler models are causing bloat. Every time a single instruction appears on a line by itself like this in a scheduler model: def: InstRW<[SBWriteResGroup2], (instregex "ANDNPDrr")>; It causes that instruction to be its own group in the generated output. And its replicated for each CPU. We should look into better using regular expressions or taking advantage of the fact that InstRW can take a list of instructions. That makes those instructions part o...

...Mar 17, 2018, at 4:04 PM, Craig Topper via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I'm sure the x86 scheduler models are causing bloat. Every time a single instruction appears on a line by itself like this in a scheduler model: > > def: InstRW<[SBWriteResGroup2], (instregex "ANDNPDrr")>; > > It causes that instruction to be its own group in the generated output. And its replicated for each CPU. We should look into better using regular expressions or taking advantage of the fact that InstRW can take a list of instructions. That makes those instructi...

...2018, at 4:04 PM, Craig Topper via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > I'm sure the x86 scheduler models are causing bloat. Every time a single > instruction appears on a line by itself like this in a scheduler model: > > def: InstRW<[SBWriteResGroup2], (instregex "ANDNPDrr")>; > > It causes that instruction to be its own group in the generated output. > And its replicated for each CPU. We should look into better using regular > expressions or taking advantage of the fact that InstRW can take a list of > instructions. That makes t...

Thanks for raising this. This is something we've recently been looking at too at Sony, as over the course of PS4's lifetime so far we've seen our clang executable on Windows approximately double in size, which isn't ideal for things like distributed build systems. A graph of clang.exe size on our internal staging branch matches yours closely with it being more of a death by a

Hi all, I recently did a run where I built clang executables on FreeBSD 12-CURRENT [1], from trunk r250000 (2015-10-11) all through r327700 (2018-03-16), with increments of 100 revisions. This is mainly meant as an archive, for easily doing bisections, but there are also some interesting statistics. From r250000 through r327700: * the total (stripped) executable size grew by approximately 43% *