search for: scheduledaginstrs

I am stuck trying to adapt my out-of-target implementation to build on SVN head (actually the v3.8 branch, rev #257626). This is currently working on the v3.7.1 sources, but the changes to 'llvm::ScheduleDAGInstrs' have me stumped as to how to revise my implementation to track the changes to this class. Our 'SHAVEAsmScheduler' derives from 'ScheduleDAGInstrs' and uses both the 'IsPostRA' and 'LiveIntervals' that were in 'ScheduleDAGInstrs', but which have now been...

In ScheduleDagInstr.cpp, a todo is mentioned to make this pass use real alias analysis information. Is anybody working on this already? I am working on a VLIW-like backend and have If-conversion working rather well, but the problem is that independent loads and stores in the if-converted blocks are not scheduled well at all. Thanks, prof. Bjorn De Sutter Computer Systems Lab Ghent University

I am working on something very(very) similar, what is the exact nature of your question? Sergei Larin -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bjorn De Sutter Sent: Friday, November 11, 2011 7:59 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] alias

Hi Sergei, thanks for considering my question. We if-convert some code, such that the basic block looks as follows after if-conversion: ld char from A into R1 p1 = R1>255? (generate the predicate) p1 | R1 = 255 (conditional execution) st char R1 to A ld char from A+1 into R2 p2 = R2>255? (generate the predicate) p2 | R2 = 255 (conditional execution) store char R2 to A+1 The problem is

We observed exact same problem, and I did put in place a mechanism to recognize and break such false dependencies right before pre-RA scheduler (in DAG->DAG lowering), but the immediate observed effect for our back end was performance reduction, since none of the current schedulers were capable of dealing with newly presented parallelism in BB (resulted in high reg pressure and

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? Does at least one store to memory? Is either access volatile? etc.), and finally queries AliasAnalysis if...

Hi all, I have a question regarding the latency of the true dependency of a store followed by an aliased load in ScheduleDAGInstrs. The latency seems to depend on the store and load being volatile or not as can be seen in the post-RA-sched debug output of the attached ARM example: $ llc -O3 -debug-only=post-RA-sched store_load_latency_test.ll ... SU(2): STRi12 %R2<kill>, %R0<kill>, 0, pred:14, pred:%noreg; me...

...d a subsequent load, thinking that they do not refer to the same underlying object when they actually do. The logic in "Merge disjoint stack slots" seems ok, except that it relies on llvm::GetUnderlyingObject[2] to determine if an instruction needs to be updated. Unfortunately, unlike ScheduleDAGInstrs' getUnderlyingObject[3], llvm::GetUnderlyingObject doesn't handle ptrtoint instructions, and in this case, fails to see that the problematic store refers to the merged stack slot. It seems to me that the logic in ScheduleDAGInstrs's getUnderlyingObject should be pushed into llvm::G...

...tioned in [1]. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-April/112348.html HTH, chenwj 2017-06-10 4:03 GMT+08:00 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw>: > Not saying I am totally understand how thing works, but I think you're > misleading > by the DAG in the class name ScheduleDAGInstrs. I only see MachineInstrs > there, no SDNode. And the comment of ScheduleDAGInstrs says, > > /// A ScheduleDAG for scheduling lists of MachineInstr. > > One place mentioning DAG is relate to constructing the dependency of SUnit, > i.e., Value2SUsMap. > > Regards, > chen...

On Jun 12, 2012, at 7:20 AM, Jordy Potman <jordy.potman at recoresystems.com> wrote: > > So in the volatile case the latency of the chain dependency is 0, while > in the non volatile case it is 1. > > I am using ScheduleDAGInstrs in a scheduler for a VLIW target and in the > volatile case the load gets incorrectly scheduled in the same cycle as > the store. Is ScheduleDAGInstrs incorrect in the volatile case or > shouldn't I rely on the latency being non zero for getting a correct > schedule? I don't li...

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 anti-dependency from the second to the third LSHL and the packetizer can bundle the instructions. If the order of the implicit-defs and implicit-use would be different (e.g., like TableGen adds them), or if I apply...

...ng, or is it because MachineCombiner may give the register based analysis an advantage? This is a check in the case of the *same Value*. In this case the Value is an argument, which is unsafe against others, but I am thinking it should at least be safe against itself... diff --git a/lib/CodeGen/ScheduleDAGInstrs.cpp b/lib/CodeGen/ScheduleDAGInstrs.cpp index 00a0b0f..cd48f51 100644 --- a/lib/CodeGen/ScheduleDAGInstrs.cpp +++ b/lib/CodeGen/ScheduleDAGInstrs.cpp @@ -584,6 +584,25 @@ static bool MIsNeedChainEdge(AliasAnalysis *AA, const MachineFrameInfo *MFI, if (!MIa->hasOneMemOperand() || !MIb->h...

...u can't ever rely on GetUnderlyingObject actually finding the real underlying object. But it sounds like "Merge disjoint stack slots" *is* relying on this (I don't know the code, it's just the impression I get from your description). Ciao, Duncan. > Unfortunately, unlike ScheduleDAGInstrs' getUnderlyingObject[3], > llvm::GetUnderlyingObject doesn't handle ptrtoint instructions, and in this > case, fails to see that the problematic store refers to the merged stack slot. > > It seems to me that the logic in ScheduleDAGInstrs's getUnderlyingObject should > be...

...next two loads %W7<def> = LDRBBui %X7<kill>, 1; mem:LD1[%scevgep99](tbaa=<0x6e02518>) %W0<def> = LDRSBWui %X0<kill>, 1; mem:LD1[%scevgep101](tbaa=<0x6e02518>) load from array 'B' and 'C', respectively. The problem occurs because ScheduleDAGInstrs does not correctly identify the true dependency between the STRBBui %W2<kill>, %X5<kill>, 1; mem:ST1[%scevgep91](tbaa=<0x6e02518>) and %W0<def> = LDRSBWui %X0<kill>, 1; mem:LD1[%scevgep101](tbaa=<0x6e02518>) instructions. AFAICT, the problem...

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 instr...

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjo...

Hi All, I am trying to construct a small optimization based on ScheduleDAGInstrs that does the following: 1. Find candidate nodes in the DAG, and speculatively modify the node (nodes). 2. After modification, try to compute the scheduled cycles of the region. 3. If the cycle number improves, go back to 1. to find the next candidate node. I am thinking using Sc...

...ory, because also anti and output edges are followed. Best regards, Jonas Paulsson -----Original Message----- From: Jonas Paulsson Sent: den 13 december 2014 14:47 To: 'Hal Finkel' Cc: Mattias Eriksson V; llvmdev at cs.uiuc.edu; Sanjin Sijaric; Tom Stellard; Andrew Trick Subject: RE: ScheduleDAGInstrs.cpp Hi, Thank you for your reply. I have tried Tom Stellards patch, but it did not resolve my particular problem. I have tried to expose this problem on public target without success. I am still however fearing that the scheduler is incorrect. I have a (bit unoptimized) case where the LLVM I/R...

...oop. The processes are using 15, 22 and 27 GB of memory but do not appear to grow further. This worked fine in the past, so appears to be a regression. These stacks seem to be prevalent: #0 0x0000000001850588 in llvm::SUnit::addPred(llvm::SDep const&, bool) () #1 0x0000000001855265 in llvm::ScheduleDAGInstrs::addChainDependency(llvm::SUnit*, llvm::SUnit*, unsigned int) () #2 0x0000000001855519 in llvm::ScheduleDAGInstrs::addChainDependencies(llvm::SUnit*, llvm::ScheduleDAGInstrs::Value2SUsMap&) () #3 0x000000000185f3ba in llvm::ScheduleDAGInstrs::buildSchedGraph(llvm::AAResults*, llvm::RegPressur...

Hi, I write again regarding buildSchedGraph(), as I am still not happy about things there. I have found at least two examples which do not work out: 1) SU(2) Store "Value A" SU(1) Store "Value A" SU(0) Load "Value A" If MIsNeedChainEdge() returns false for SU(0) and SU(1), SU(0) is inserted into RejectedMemNodes and removed from its MemUses SU list, as this