similar to: [LLVMdev] [PATCH] Debug SelectionDAG & SDUse

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

Do you have a fix for the blackfin codegen? That would be a great way to motivate this patch. Otherwise, at 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

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

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?

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 finally diagnosed it today. > > One possible fix comes down to holding SDUses about to be

On Mar 2, 2010, at 8:58 AM, David Greene wrote: > On Monday 01 March 2010 20:34:07 Dan Gohman wrote: >> Do you have a fix for the blackfin codegen? That would be a great >> way to motivate this patch. > > I'm not following you. Why does a fix for a bug have anything to do > with a patch that catches bugs? It helps people understand what's being checked. On an

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 constructor private. In this case,

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 have expected that

Thanks for noticing this, Geoff. I just landed r268050 which add a cmake option for this (and unifies XDEBUG and EXPENSIVE_CHECKS). This might make it easier to setup some build bots. Thank you, Filipe On Fri, Apr 22, 2016 at 8:40 PM, Geoff Berry via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Bugs filed: > 27488 <https://llvm.org/bugs/show_bug.cgi?id=27488> librarie

On Thursday 25 February 2010 21:27:21 David A. Greene wrote: > Thanks. I don't have the source right in front of me. I'll take a look > when I can. Here's a fixed patch. It shows the same iterator errors I'm seeing with 2.5. Run make-check with a Debug+Checks compiler. I will file a bug once I have a proper internet connection. :-/ -Dave

On Feb 25, 2010, at 2:24 PM, David Greene wrote: > 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

On Monday 01 March 2010 20:34:07 Dan Gohman wrote: > Do you have a fix for the blackfin codegen? That would be a great > way to motivate this patch. I'm not following you. Why does a fix for a bug have anything to do with a patch that catches bugs? > Otherwise, at a glance, it appears you fixed the issues I raised, > so this is fine, if it catches real bugs. Oh, it catches real

Yeah, they are just triggered by lit check tests. I’ll file some bugs today, though it looks like Quentin may have already filed bugs for some of these. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday,

Hi All, Are there any bots that do any testing with clang/llvm built with XDEBUG (i.e. expensive checking)? I'm seeing 36 lit tests that currently hit asserts that are checked when XDEBUG is enabled. The checks that I'm hitting are: - DominatorTree::verifyDomTree() - DAGTypeLegalizer::PerformExpensiveChecks() - SelectionDAG checkForCyclesHelper Are these known issues or should I file

Hello, As part of enhancing atomic operations in the ARM backend, we need to extend the Ops array in AtomicSDNode. This array is a private member of AtomicSDNode, so it's only accessible within 85 lines of code, none of which have anything to do with its size. Therefore, increasing the size of Ops shouldn't at all affect the behaviour of LLVM, we supposed. Much to our surprise, this

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

On Mar 1, 2010, at 7:26 AM, David Greene wrote: > >> Perhaps this can be fixed by making the code skip the ReplaceUses >> call in the case where there are no uses to replace. That's not trivial >> to detect though. > > Why not just check the same thing the added asserts check? You mean ->getOpcode() == ISD::DELETED_NODE? That's not fundamentally any

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

On Monday 01 March 2010 13:41:12 Dan Gohman wrote: > On Mar 1, 2010, at 7:26 AM, David Greene wrote: > >> Perhaps this can be fixed by making the code skip the ReplaceUses > >> call in the case where there are no uses to replace. That's not trivial > >> to detect though. > > > > Why not just check the same thing the added asserts check? > > You