similar to: [LLVMdev] SDUse

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

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

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

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

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

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

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

Even if I turn to -O0 [in other words, no optimisation passes at all], it takes the same amount of time. The time is spent in 12.94% lacsap lacsap [.] llvm::SDNode::use_iterator::operator== 7.68% lacsap lacsap [.] llvm::SDNode::use_iterator::operator* 7.53% lacsap lacsap [.] llvm::SelectionDAG::ReplaceAllUsesOfValueWith 7.28% lacsap

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

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 Monday 01 March 2010 20:32:07 Dan Gohman wrote: > > No, what I mean is the thing under UI at the point of call to > > AddModifiedNodeToCSEMaps gets deleted. So UI is invalid and when > > we loop back around and check it against UE we blow up with a > > singular iterator error. > > UI is incremented before AddModifiedNodeToCSEMaps is called, so > I'm still

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

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

On Thursday 25 February 2010 22:38:03 David A. Greene wrote: > 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

On Friday 26 February 2010 09:46:41 David Greene wrote: > On Thursday 25 February 2010 22:38:03 David A. Greene wrote: > > 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

Hi, Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven: 1) Download llvm-gcc4 binary and llvm. Compile and run make check. I did a debug build on OSX 10.4.9 and everything went fine. Results of "make check" (see ppc.log): === Summary === # of expected passes 1630 # of unexpected failures 21 # of expected failures 2

On Friday 26 February 2010 19:09:01 Dan Gohman wrote: > I've now looked at your latest patch. In summary, it does expose a > subtle problem. I haven't seen anything that here would lead to > observable misbehavior yet though. Well, I'm definitely observing misbehavior. I know it has something to do with local changes here but I haven't isolated it yet. >

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 -

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