search for: picknodetoschedulebottomup

...ule sched - 0 2 1 3 5 7 6 8 4 SU(0) 0 SU(1) 1 0 SU(2) 1 0 SU(3) 3 2 1 0 SU(4) 1 0 SU(5) 1 0 SU(6) 1 0 SU(7) 3 1 0 SU(8) 1 0 So, the problem comes back to trying to find the physical address of a 'CallResource' in the later part of PickNodeToScheduleBottomUp(). Robert ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com] Sent: 20 August 2013 22:57 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] PrescheduleNodesWithMultipleUses() causing failure in PickNode...

...please! Robert ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com] Sent: 21 August 2013 11:02 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PrescheduleNodesWithMultipleUses() causing failure in PickNodeToScheduleBottomUp() ??? Here is a bit more data. After PrescheduleNodesWithMultipleUses has been run, the following Predecessor/Successor links are 'dumpAll'ed. (I attach the full dumpAll before & after "Prescheduling SU #7 next to PredSU #4 to guide scheduling in the presence of multiple uses&quot...

Hi, I have an assert firing due to PickNodeToScheduleBottomUp(): 1. having a CallResource in use pushing an interference of current SUnit. 2. having no more SUnits in the AvailableQueue 3. The only interference being the SUnit that just failed due to a Call Resource. 4. An attempt to duplicate this node which has the 'Call Resource' a...

...y around! Robert ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com] Sent: 21 August 2013 18:34 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PrescheduleNodesWithMultipleUses() causing failure in PickNodeToScheduleBottomUp() ??? Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <---...

On Thu, Aug 22, 2013 at 4:15 AM, Robert Lytton <robert at xmos.com> wrote: > > > Outstanding issues > ============ > > 1. Is it too aggressive in searching predecessors and successors? > Should the algorithm give up and assume the worst if the depth of > search reaches a predefined limit? > > 2. Should the initial search for 'SetUp1' and

Hi I have brought everything together in this email. The problem ======== Take the following DAG (arrow to predecessor): SetUp2 SetUp1 ^ ^ | | | | Destroy2---->PredSU <----SU ^ ^ ^ | | | | | | ----------- | ---------

...ys::PrintStackTrace(llvm::raw_ostream&) (llvm.inst/bin/clang+++0x13c9c68) #1 0x00000000013ca376 SignalHandler(int) (llvm.inst/bin/clang+++0x13ca376) #2 0x00007f978e97ed10 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d10) #3 0x0000000001c906a8 (anonymous namespace)::ScheduleDAGRRList::PickNodeToScheduleBottomUp() (llvm.inst/bin/clang+++0x1c906a8) #4 0x0000000001c8f0d5 (anonymous namespace)::ScheduleDAGRRList::Schedule() (llvm.inst/bin/clang+++0x1c8f0d5) #5 0x0000000001c16221 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (llvm.inst/bin/clang+++0x1c16221) #6 0x0000000001c13b86 llvm::SelectionDAGISel::SelectAl...

...39;s a SystemZ target problem. However, I'm unfamiliar with the scheduling code, so I'm not entirely certain what the correct behaviour is. My rough understanding of the problem is that, while attempting to pick a node to schedule, we're running out of candidates (in ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to copy a node, and in the process, we call getPhysicalRegisterVT. This function asserts that the MCInstrDesc associated with the node will have ImplicitDefs, but in our case, it does not. In short: does this seem to be a problem of missing information in the MCInstrDesc, o...

.... > However, I'm unfamiliar with the scheduling code, so I'm not entirely > certain what the correct behaviour is. > > My rough understanding of the problem is that, while attempting to pick > a node to schedule, we're running out of candidates (in > ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to > copy a node, and in the process, we call getPhysicalRegisterVT. This > function asserts that the MCInstrDesc associated with the node will have > ImplicitDefs, but in our case, it does not. > > In short: does this seem to be a problem of missing informati...

...nfamiliar with the scheduling code, so I'm not entirely > > certain what the correct behaviour is. > > > > My rough understanding of the problem is that, while attempting to pick > > a node to schedule, we're running out of candidates (in > > ScheduleDAGRRList::PickNodeToScheduleBottomUp). This causes us to try to > > copy a node, and in the process, we call getPhysicalRegisterVT. This > > function asserts that the MCInstrDesc associated with the node will have > > ImplicitDefs, but in our case, it does not. > > > > In short: does this seem to be a pro...