similar to: [LLVMdev] ScheduleDAG Question

On Thu, Sep 3, 2009 at 9:48 AM, David Greene<dag at cray.com> wrote: > I'm debugging a ScheduleDAG problem.  Somehow a load appearing > before a call in the source gets scheduled after the call. > Since the callee modifies the location loaded from, wrong answers result. > > Looking at the dag with -view-sched-dags, I don't see an edge from the > load to depend on

On Thursday 03 September 2009 16:04, Eli Friedman wrote: > My first step would be to make sure there's an appropriate edge in the > selection DAG... there's a possibility something could get messed up > by legalization or the dagcombiner. I turned off dagcombine and it didn't help. > Since scheduling and selection is mostly within a block, hopefully it > wouldn't

On Thu, Sep 3, 2009 at 5:55 PM, David Greene<dag at cray.com> wrote: > On Thursday 03 September 2009 18:22, David Greene wrote: > >> > Since scheduling and selection is mostly within a block, hopefully it >> > wouldn't be too hard to come up with a testcase? >> >> Yep, I've got a much reduced testcase now (and converted from Fortran >> to C

On Thursday 03 September 2009 18:22, David Greene wrote: > > Since scheduling and selection is mostly within a block, hopefully it > > wouldn't be too hard to come up with a testcase? > > Yep, I've got a much reduced testcase now (and converted from Fortran > to C which makes things much easier to work with). I'm going to test > against TOT and see if I see

Long story short: https://llvm.org/bugs/show_bug.cgi?id=31890 The backend fails to schedule a given DAG, the reason being that there is an instruction and it glue that needs to be broken apart as they can't be scheduled consecutively. See attached file for a picture of the DAG. Not sure what's the best course of action is, and not sure why this isn't a problem for the X86 backend

Would it not make sense to refactor the code so those don't use glue rather than emitting them with glue and then getting rid of it. There are times when we would like to emit these in separate blocks but can't (presumably because of the glue). On Tue, Feb 7, 2017 at 9:15 PM, James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That's seems really odd that

I don't think that'd work, because it leaves all other backends broken. AFAICT, your transform is simply not a legal transform, with the way the ADDC/ADDE opcodes are currently defined, and to do it you really need to fix the opcode definitions to not involve glue, first. I also note that your transform doesn't actually trigger at all on this particular test case on x86, because the

On Thursday 03 September 2009 20:41, Eli Friedman wrote: > > My little testcase definitely has missing edges in the sched dag and > > sunit dag.  Where do edges from loads of globals to calls get added? > >  That's what's missing here. > > They should be there from the very beginning, when the selection dag is > built. Nope, not there. I've attached the

Also you might need to check use PostRASchedulerList or PostMachineScheduler, PostRASchedulerList is considered deprecated as mentioned 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 >

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

Hello, I was trying to interface a custom backend instruction scheduler with llvm code when I realize something terrible. The scheduling code builds a graph made up of SUnit * nodes (see ScheduleDAG*.{cpp,h}). These SUnits nodes are allocated via a std::vector< SUnit >. This isn't a problem as long as the pointers are taken after the vector is fully filled and the vector never changes

Hello, I am working with the SelectionDAG/ScheduleDAG framework to implement a variation of the List scheduling Algorithm in LLVM. I was trying to understand the existing List scheduler implementation in LLVM. I have a doubt about the SUnits structure which contain flagged nodes together. The instructions within a Sunit are scheduled as a single unit. My understanding is that the nodes in the

Andrew Trick <atrick at apple.com> writes: >> When I asked about enhancing scheduler heuristics a month or so ago, I >> got a response about a MachineInstr scheduler and that that was the way >> of the LLVM future. Is that so? Is the ScheduleDAG going away? > > You sent a lengthy RFC on Apr 20 that demonstrated you aren't > following developments on trunk.

On Thursday 03 September 2009 21:13, David Greene wrote: > Hmm...except there's a little dashed blue line from the call to the chain > (I think) field of the load. Is that the dependence I want? I don't know > how to read these graphs. Interesting. So with -view-legalize-dags, that little dashed blue line has moved from the load to the store that feeds the load. That's

Hi Andy, The thing is that I was trying to build a sched graph in other places than these two standard scheduling passes. For instance, in pre-emit. I would like to reschedule a basic block on my vliw target just before assembly emission. I tried to add SUnits for hazards in an experiment, but this gave very weird errors... even while allocating extra space in SUnits vector. For some function, I

After removing CALL64m, the resulting DAG has a cycle that cannot be scheduled. I've attached a PDF of the DAG before instruction selection (-view-isel-dags), and after instruction select (-view-sched-dags). Notice how the flag/chain relationships between MOV64rm and CALL64r make it impossible to schedule. Here's the code being compiled: define ccc void @ArgsFree() nounwind { entry:

I'd think i1 would be the proper and correct choice for a carry flag for the generic instruction. I expect that would also make UADDO/USUBO redundant with ADDC/SUBC (which would seem a good outcome). You'd need to make sure the right thing happened when converting from ADDC's 1-bit carry in/out to X86ISD::AD[DC]'s EFLAGS i/o. Right now the conversion can get away with assuming

Oh yes you're right, I missed that :) But the point still hold. Amaury Pouly 2010/8/8 Eugene Toder <eltoder at gmail.com> > > Not only this code does not compile with NDEBUG set > > I may be missing something, but why does it not compile with -DNDEBUG? > assert() macro expands to noop when NDEBUG is set. > > Eugene > > On Sun, Aug 8, 2010 at 2:19 PM, Amaury

On Feb 21, 2013, at 9:11 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > I am trying to add Hazard scheduling nodes after buildSchedGraph(), with a scheduler derived from ScheduleDAGInstrs. I get weird errors, so I wonder what I am doing wrong? > > What I am doing right now is: > > I have a created MI with opcode HAZARD that does not have

Hi, I am trying to add Hazard scheduling nodes after buildSchedGraph(), with a scheduler derived from ScheduleDAGInstrs. I get weird errors, so I wonder what I am doing wrong? What I am doing right now is: I have a created MI with opcode HAZARD that does not have parent, and I greate a SUnit(HazardMI). I use this one HazardMI for all hazard nodes. I remove all edges using removePred. I insert