search for: scheduledag

...rwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269. ../../../../../llvm-gcc-4.0.src/libstdc++-v3/libsupc++/eh_alloc.cc: 182: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs> for instructions. make[7]: *** [eh_alloc.lo] Error 1 make[6]: *...

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 the call. How is this supposed to be...

...eduler to improve it. Specifically, we are working to get loads and stores to move past each other when possible. 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? We found a thread started by Hal late last year with a patch from him to do exactly what we are trying to do - free up load/store motion. The discussion didn't really seem to come to a resolution and the patch doesn't appear in trunk. So we are in a quandry. Do we continue o...

...ng to go in. Is > the compile time hit too much? Note that sometimes compile time > improves with this patch. > > I'd like to get this in ASAP so I can start merging other things back to > upstream. > Please see bug #2155, I am seeing an additional testsuite failure with ScheduleDAG patch. I am not saying there is any problem with ScheduleDAG patch itself, it may be just exposing a previously hidden bug. [I tried to add you to the Cc: of the bugreport, but bugzilla didn't find your email address] Best regards, --Edwin

...ecifically, we are working to get loads and stores to > move past each other when possible. > > 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. That's perfectly fine, but if you want to use the new scheduler before it is mature, you'll need to follow trunk. > We found a thread started by Hal late last year with a patc...

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 the call. &gt...

Attached is a patch to fix a GLIBCXX_DEBUG error in ScheduleDAGRRList. The problem is that calls to CapturePred may reprioritize elements in the priority queue, violating streak weak ordering requirements. To fix this, I introduced a reference wrapper for containers to obtain access to the SUnitVec used by std::priority_queue. When CapturePred runs, it call...

On Monday 21 January 2008 10:41, David Greene wrote: > > >> Can you clarify? Is this 1.7% slowdown of scheduling time or overall > > >> codegen time? If it's the later, then it seems a bit too much. Also, > > >> please test it with all the MultiSource/Applications. > > > > > > It's 1.7% overall. > > > > That seems somewhat

I am tracking down a tricky bug involving select/CMOV and scheduling. In my test, I have a float select that has to be implemented with a diamond CFG by the scheduler. The high level ScheduleDAGSDNodes::EmitSchedule does this: for (unsigned i = 0, e = Sequence.size(); i != e; i++) { [...] Emitter.EmitNode(SU->getNode(), SU->OrigNode != SU, SU->isCloned, VRBaseMap); [...] } TheInstrEmitter::EmitMachineNode does this: if (II.usesCustomInser...

...s sent out a couple of days ago. I don't see any issue with bringing Boost code into llvm tree. However, does it make sense to move the license to the top of the file? Chris? Evan On Dec 17, 2007, at 10:17 AM, David Greene wrote: > Attached is a patch to fix a GLIBCXX_DEBUG error in ScheduleDAGRRList. > > The problem is that calls to CapturePred may reprioritize elements > in the > priority queue, violating streak weak ordering requirements. > > To fix this, I introduced a reference wrapper for containers to > obtain access > to the SUnitVec used by std::priori...

...X86 backend either. I'm looking for advice on the best course of actions. As I see it, the option are: 1/ add extra logic in the DAGCombiner to make sure this doesn't happen. I don't see a way this could be done cheaply and overall I don't think this is the best option/ 2/ Have the ScheduleDAG machinery detect this case and break up the glue, for instance via breaking up (adde X, Y, Carry) into (add (add X, Y)n (adde 0, 0, Carry)) or something alike when the situation present itself. 3/ Do whatever the X86 backend does, which I'm not sure what it is. Advice ? Thanks in advance, Am...

On Friday 04 January 2008 12:59, Evan Cheng wrote: > On Jan 2, 2008, at 12:44 PM, David Greene wrote: > > On Saturday 22 December 2007 02:33, Evan Cheng wrote: > >>> After some very simple testing, I see slowdowns of around 1.7%. I > >>> assume > >>> this is ok, but want to check. > >> > >> Can you clarify? Is this 1.7% slowdown of

...] /lib/libc.so.6(__assert_fail+0xfd)[0x4caae859] /home/lefever/work/install/bin/llc(llvm::cast_retty<llvm::ConstantSDNode, llvm::SDOperand>::ret_type llvm::cast<llvm::ConstantSDNode, llvm::SDOperand>(llvm::SDOperand const&)+0x4c)[0x83f6af6] /home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitNode(llvm::SDNode*, llvm::DenseMap<llvm::SDNode*, unsigned int, llvm::DenseMapKeyInfo<llvm::SDNode*> >&)+0x8b2)[0x86ab9fc] /home/lefever/work/install/bin/llc(llvm::ScheduleDAG::EmitSchedule()+0x283)[0x86abf7d] /home/lefever/work/install/bin/llc[0x861cada] /home/lefever/work/i...

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

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

...e two extract_vector_elt nodes. Am I reading the graph correctly? 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. Is the code that's supposed to do this in ScheduleDAGBuild.cpp? Thanks for your help. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: reset.builddag.ps Type: application/postscript Size: 40025 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

On Thu, Sep 3, 2009 at 7:24 PM, David Greene<dag at cray.com> wrote: > 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

On Monday 17 December 2007 13:39, Evan Cheng wrote: > My only concern is the potential compile time impact. Do you see any? I don't notice any, but then I'm not particularly looking for that either. I'll run some tests. I also accidentally included some debugging code I added to track down this prioritization problem (the queue dumping code). I'll remove that before I

On Mon, 17 Dec 2007, David Greene wrote: > On Monday 17 December 2007 13:39, Evan Cheng wrote: >> My only concern is the potential compile time impact. Do you see any? > I don't notice any, but then I'm not particularly looking for that either. > I'll run some tests. Thanks. 5% slowdowns are generally not noticable, but we care :) > I also accidentally included