search for: sduse

I just found a major bug in SelectionDAG. Well, I found it several weeks ago and finally diagnosed it today. One possible fix comes down to holding SDUses about to be processed in a queue. But this would require the SDUse copy constructor to be public. Why is it private and unimplemented right now? What's the assumption that's trying to protect? -Dave

SDUse's Prev and Next members implement a use list. Copying them probably wouldn't immediately break anything, but it wouldn't be meaningful. Dan On Feb 24, 2010, at 3:08 PM, David Greene wrote: > I just found a major bug in SelectionDAG. Well, I found it several weeks ago > and fin...

I need a review of this patch and if it looks sane, someone to apply it to their local sources and run tests in Debug+Checks mode. The patch replaces the intrusive SDUse list with a std::list<> when XDEBUG is active. I believe I've maintained the semantics of the SDUse list but I need a double-check. The patch exposes all kinds of problems in Debug+Checks mode. Right now most of them appear to be caused by either garbled data or assigning an SDUse to...

On Wednesday 24 February 2010 18:47:19 Dan Gohman wrote: > SDUse's Prev and Next members implement a use list. Copying them > probably wouldn't immediately break anything, but it wouldn't be > meaningful. I understand that the copied SDUse wouldn't be represented in the list, so I can understand the general reasons for making the copy cons...

Are SDUses ever allowed to be part of more than one list? I would think not due to the intrusive nature of the list links. However, this is what I am seeing with some testcases on trunk. I am putting together a patch that shows these kinds of problems in XDEBUG mode. I'll post it ASAP....

...rted Tests : 66 > > [x86_64-off-dbg]: Expected Passes : 5001 > [x86_64-off-dbg]: Expected Failures : 33 > [x86_64-off-dbg]: Unsupported Tests : 66 > [x86_64-off-dbg]: Unexpected Failures: 5 > > Why would changing the test harness change the result of the tests? SDUse::setInitial should initialize List to null in your patch. You're probably seeing random uninitialized data noise without that. (Though valgrind wouldn't notice this because of the aggressive reuse of allocated memory.) Also, the replacement getOperandNo is returning the index in the use li...

...iour of LLVM, we supposed. Much to our surprise, this isn't as trivial. Even this innocuous change: ==================== --- a/include/llvm/CodeGen/SelectionDAGNodes.h +++ b/include/llvm/CodeGen/SelectionDAGNodes.h @@ -1068,6 +1068,7 @@ public: /// class AtomicSDNode : public MemSDNode { SDUse Ops[4]; + SDUse buffer; void InitAtomic(AtomicOrdering Ordering, SynchronizationScope SynchScope) { // This must match encodeMemSDNodeFlags() in SelectionDAG.cpp. ==================== -- makes LLVM fail 83 regression tests, basically everything related to the atomic ops, in a bunch of un...

...ValueWith 7.28% lacsap lacsap [.] llvm::SDNode::use_iterator::operator++ 5.59% lacsap lacsap [.] llvm::SDNode::use_iterator::operator!= 4.65% lacsap lacsap [.] llvm::SDNode::hasNUsesOfValue 3.82% lacsap lacsap [.] llvm::SDUse::getResNo 2.33% lacsap lacsap [.] llvm::SDValue::getResNo 2.19% lacsap lacsap [.] llvm::SDUse::getNext 1.32% lacsap lacsap [.] llvm::SDNode::use_iterator::getUse 1.28% lacsap lacsap [.] llvm::SDUse::getUser Here's...

On Thursday 25 February 2010 20:20:56 Dan Gohman wrote: Wrong thread? > SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) Why isn't the default constructor called? I would h...

Just so this doesn't get lost in threads dealing with SelectionDAG issues, I'd like to post this patch for review. It changes the SDUse list from an intrusive list to a std::list<> under XDEBUG. This allows us to use the debugging features of the standard library to track down stubborn bugs. I've used this to diagnose in issue in SelectionDAG in our sources and also in the Blackfin codegen on TOT. Please review, commen...

...inc:470:0 #2 0x00007f08faa9cb55 llvm::sys::RunSignalHandlers() /llvm/lib/Support/Signals.cpp:44:0 #3 0x00007f08faa9df4b SignalHandler(int) /llvm/lib/Support/Unix/Signals.inc:256:0 #4 0x00007f08f994e4a0 (/lib/x86_64-linux-gnu/libc.so.6+0x354a0) #5 0x00007f08fae80078 llvm::SDUse::addToList(llvm::SDUse**) /llvm/include/llvm/CodeGen/SelectionDAGNodes.h:299:0 #6 0x00007f08fae80b2b llvm::SDNode::addUse(llvm::SDUse&) /llvm/include/llvm/CodeGen/SelectionDAGNodes.h:801:0 #7 0x00007f08fae80f6c llvm::SDUse::setInitial(llvm::SDValue const&) /llvm/include/llv...

...234, reg1 noop noop add reg1, 1 load 0x1236, reg2 can be safely transformed to: load 0x1234, reg1 load 0x1236, reg2 noop add reg1, 1 ---- It pleased us quite a lot when we found the HazardRecognizer-class. Without much effort we could assist LLVM to transform code like shown above (with simple (SDUse, delayCount)-map). Unfortunately we found now out that the HazardRecognizer is used only before register allocation, and the register allocator obviously may reschedule instructions, but doesn't take hazard recognition into account. Is there a switch/option we overlooked to bind the hazardRec...

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

...86_64-off-dbg]: Expected Passes : 5001 >> [x86_64-off-dbg]: Expected Failures : 33 >> [x86_64-off-dbg]: Unsupported Tests : 66 >> [x86_64-off-dbg]: Unexpected Failures: 5 >> >> Why would changing the test harness change the result of the tests? > > SDUse::setInitial should initialize List to null in your patch. You're > probably seeing random uninitialized data noise without that. > (Though valgrind wouldn't notice this because of the aggressive reuse > of allocated memory.) > > Also, the replacement getOperandNo is returnin...

...a glance, it appears you fixed the issues I raised, so this is fine, if it catches real bugs. Dan On Mar 1, 2010, at 10:02 AM, David Greene wrote: > Just so this doesn't get lost in threads dealing with SelectionDAG > issues, I'd like to post this patch for review. It changes the SDUse > list from an intrusive list to a std::list<> under XDEBUG. This allows > us to use the debugging features of the standard library to track down > stubborn bugs. > > I've used this to diagnose in issue in SelectionDAG in our sources and > also in the Blackfin codegen...

...an be safely transformed to: > > load 0x1234, reg1 > load 0x1236, reg2 > noop > add reg1, 1 > > ---- > > It pleased us quite a lot when we found the HazardRecognizer-class. > Without much effort we could assist LLVM to transform code like shown > above (with simple (SDUse, delayCount)-map). > > Unfortunately we found now out that the HazardRecognizer is used only > before register allocation, and the register allocator obviously may > reschedule instructions, but doesn't take hazard recognition into > account. The register allocator doesn't...

On Thursday 25 February 2010 16:17:10 David Greene wrote: > On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: > > On Feb 25, 2010, at 12:01 PM, David Greene wrote: > > > I am seeing a whole lot of failures in the tests on trunk. From > > > discussions with Chris and others, I should not be seeing this. > > > > Does 'make check-lit' pass for

On Thursday 25 February 2010 16:07:59 Chris Lattner wrote: > On Feb 25, 2010, at 12:01 PM, David Greene wrote: > > I am seeing a whole lot of failures in the tests on trunk. From > > discussions with Chris and others, I should not be seeing this. > > Does 'make check-lit' pass for you in llvm/test? Nope. In fact I am seeing more failures in debug mode now. But what

Hello. I'm writing a back end for a RISC processor (similar to BPF) with a large SIMD unit. I tried in the last days to make llc compile to SIMD code the following LLVM program: define i32 @foo(i32* %A, i32* %B, i32* %C, i32 %N) #0 { entry: ;vector.body: ; preds = %vector.body, %vector.body.preheader.split.split %0 = getelementptr inbounds i32, i32* %A, i64 0 ; i64 %index ; Alex: I

...at is NULL (hence the segfault). More exactly, if we use GDB we see that at the i-sel of the store we have: ┌──/home/asusu/LLVM/llvm38Nov2016/llvm/include/llvm/CodeGen/SelectionDAGNodes.h │858 /// Initialize the operands list of this with N operands.│ │859 void InitOperands(SDUse *Ops, const SDValue *Vals, unsigned N) {│ │860 for (unsigned i = 0; i != N; ++i) {│ │861 Ops[i].setUser(this);│ >│862 Ops[i].setInitial(Vals[i]);│ │863 } Here N = 4 and the Ops are: {Val = {Node = 0x6e5610, ResNo = 0}, User = 0x6e6940, Pre...