similar to: [LLVMdev] e-mail down

A simulator should be expecting the machine opcodes not macros. LD shouldn't care at all as long as the object format plays well. I would think it would be better to fix the simulator. Jack ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of llvmdev-request at cs.uiuc.edu [llvmdev-request at cs.uiuc.edu] Sent: Thursday,

I had the same problem, actually. Is the HTML file just too heavy? It makes it hard to compare results from your workstation against the buildbots. Reid On Thu, Jul 23, 2009 at 3:22 PM, David Greene<dag at cray.com> wrote: > If I click on a "View Details" link for a particular nightly test, my browser > sits there waiting until I tell it to stop.  I something wrong with

We are experiencing serious load/memory issues on llvm.org and unfortunately, there is not anything we can do about it. This means that because the nightlytest page needs to access a mysql database, it will be very very slow. Bugzilla will be slow too. We have a machine being ordered, but it will take time to arrive and time to setup. Until then, I'm asking people to please try to be

Thanks for the help Reid! I frequently look at the online doxygen, but sometimes its difficult to determine the correct replacement when a method is removed from LLVM. In this particular case, I knew which new CallInst constructor to use, I just couldn't figure out the proper syntax. At any rate, I really appreciate your help!! Reid Spencer wrote: > On Tue, 2007-03-06 at 22:44 -0600,

On Wednesday 11 July 2007 17:03, Devang Patel wrote: > Hi All, > > llvm-gcc-4-2 development branch is now open for development at > > llvm.org/svn/llvm-project/llvm-gcc-4-2 > > It is not yet ready, it can not even bootstrap. I welcome LLVM > developers to test and apply fixes! How does this relate to the current llvm-gcc? Is that version still going to be added to the

Ok, I've tracked down the problem I've had bootstrapping llvm-gcc. The culprit is in TreeToLLVM::EmitMemCpy: void TreeToLLVM::EmitMemCpy(Value *DestPtr, Value *SrcPtr, Value *Size, unsigned Align) { const Type *SBP = PointerType::get(Type::Int8Ty); const Type *IntPtr = TD.getIntPtrType(); Value *Ops[4] = { CastToType(Instruction::BitCast,

Dear All, To add to this, what you want to do is find the appropriate debug stop point intrinsic and then use it to look up the information for that instruction. Here is some sample code from SAFECode that finds the debug information associated with a CallInst (LLVM call instruction) held in the variable CI. It uses the findStopPoint() function in llvm/Analyis/DebugInfo.h: // // Get the

Forgot to CC the list. I'm looking into it. -Dave ---------- Forwarded Message ---------- Subject: Re: [LLVMdev] Bootstrap Failure Date: Thursday 12 November 2009 15:50 From: David Greene <dag at cray.com> To: Bill Wendling <wendling at apple.com> On Thursday 12 November 2009 15:49, you wrote: > These are the likely culprits. David, it looks

Please unsubscribe me from this list. Sujatha Gurumurthy Staffing Consultant/Talent Advisor UMG - Ultra Mobile Group sujatha.gurumurthy at intel.com US ERP Manager Interested in Employee Referral Program Visit referral.intel.com/ Intel USA Employee Referral Program Group 100 Best Companies to Work For 2011: Intel - INTC - from FORTUNE -----Original Message----- From: llvmdev-bounces at

On Tue, 2007-03-06 at 22:44 -0600, Ryan M. Lefever wrote: > To create a new CallInst I used to call the following constructor: > > CallInst(Value *F, const std::vector<Value*> &Par, const std::string > &Name = "", Instruction *InsertBefore = 0); > > However, it seems as though that constructor has been removed. I assume > that I'm suppossed to

On Monday 02 July 2007 23:24, David A. Greene wrote: > > > - Changing the API > > > a) Template it to take two iterators. This causes code size bloat. > > This seems like the right solution to me. Unless llvm is running on > extremely limited memory embedded systems, the extra code space > shouldn't be an issue. It turns out this wasn't quite a simple as

If I click on a "View Details" link for a particular nightly test, my browser sits there waiting until I tell it to stop. I something wrong with the server? I thought I could do this ok yesterday. -Dave

On Wednesday 11 July 2007 18:55, David Greene wrote: > I ask because I'm ready to commit the CallInst interface changes and it > will break llvm-gcc. There is no way to preserve the interfaces llvm-gcc > needs because there are three places in the llvm-gcc code where > the old interface conflicts with the new one (passing two Value*'s vs. > passing two iterators to a

On May 9, 2012, at 2:00 PM, dag at cray.com wrote: > Jim Grosbach <grosbach at apple.com> writes: > >>> - How difficult do you expect a backport to 3.1 to be? We have to work >>> from 3.1. Trunk is too buggy. > >> You've stated that trunk is too buggy for you to work from on multiple >> occasions. Can you elaborate? That doesn't match my

David, Would you mind documenting what you did with AddedComplexity for the 'less fortunate' on the wiki? Thanks, Justin. On Mon, Apr 6, 2009 at 9:47 PM, David Greene <dag at cray.com> wrote: > On Monday 06 April 2009 13:31, David Greene wrote: > > What's a reliable way to prefer one patterns over another? I have two > > patterns with different predicates.

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

Hi Dave, As an exercise I tried to fix this myself, and I think I have a working patch (attached). My own tests are all working wonderfully, and at fantastic performance! I'm looking forward to your patch to see whether we used the same approach or whether things could be improved further. Anyway, I've re-profiled the code and found ComputeLiveInBlocks to be the main hotspot now. Again

On Wed, 9 May 2012 16:00:34 -0500 <dag at cray.com> wrote: > Jim Grosbach <grosbach at apple.com> writes: > > >> - How difficult do you expect a backport to 3.1 to be? We have to > >> work from 3.1. Trunk is too buggy. > > > You've stated that trunk is too buggy for you to work from on > > multiple occasions. Can you elaborate? That

On Wed, Feb 10, 2010 at 12:02 AM, David Greene <dag at cray.com> wrote: > Since 2.7 is getting close to code freeze, I'd like to see if I can get in our > changes to track non-temporal memory operations into trunk. > > As discussed earlier, I was hoping to do this via metadata.  It's pretty clear > how to attach the data to Instructions, but after that, I'm not

Hi Dave, Did that patch of yours ever make it into trunk? I can't seem to find any related checkin for PromoteMemoryToRegister.cpp. I've been doing some extra profiling lately and the RewriteSingleStoreAlloca function alone is taking a whopping 63% of execution time. Thanks! Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]