similar to: [LLVMdev] misc CVS patches

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] misc CVS patches"

2005 Apr 20
3
[LLVMdev] misc CVS patches
On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer wrote: > While trying to hunt down a codegen bug (not yet found) ... Have you considered using bugpoint for your codegen debugging needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > I've collected some small patches you might find useful. Sweet! > Please review and apply as you see fit. I've
2005 Apr 20
8
[LLVMdev] misc CVS patches
On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >
2005 Apr 21
0
[LLVMdev] Need help with bugpoint for codegen problem
On Fri, Apr 22, 2005 at 01:46:53AM +0200, Markus F.X.J. Oberhumer wrote: > Debugging code generator problem! > <cbe><gcc><program>Warning: While generating reference output, program > exited with > non-zero exit code. This will NOT be treated as a failure. > > *** The C backend cannot match the reference diff, but it is used as the > 'known good'
2005 Apr 22
0
[LLVMdev] Need help with bugpoint for codegen problem
On Fri, Apr 22, 2005 at 03:13:44AM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > >>[...] > >>bugpoint: Unknown command line argument '-instcombine-load-vn'. Try: > >>'bugpoint --help' > > > >You need a space between -instcombine and
2005 Apr 21
0
[LLVMdev] misc CVS patches
On Thu, Apr 21, 2005 at 05:56:43PM +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > >This patch can't be applied. Not all platforms have getgid() and > >getuid() functions. Placing non-portable code outside of lib/System > >is deprecated. We set the values to 1000 by default because in > >general the uid/gid doesn't matter in an archive and the 1000
2005 Apr 20
0
[LLVMdev] misc CVS patches
On Wed, Apr 20, 2005 at 01:48:41PM +0200, Markus F.X.J. Oberhumer wrote: > In case you really prefer outside patches for this issue, here is a > first version on a small subset of the sources. Committed. > But I'd think you would want to handle this "in house". I think you're right, it'll be easier that way. ;) -- Misha Brukman :: http://misha.brukman.net ::
2004 Jun 23
0
[LLVMdev] weird issue with mem2reg, should have guessed
What's different about code that's been mem2reg'd from straight front end code, or anything that mem2reg hasn't been run on? PHINODES! It appears to be crashing when I try to cast a Value* that's really a BB* (from the PHInode operands) to a User*, insteresting since I am dyn_casting. I just caught this on cerr though (printing out what the Value* was each time). Let me
2005 Apr 21
0
[LLVMdev] misc CVS patches
Markus, This patch can't be applied. Not all platforms have getgid() and getuid () functions. Placing non-portable code outside of lib/System is deprecated. We set the values to 1000 by default because in general the uid/gid doesn't matter in an archive and the 1000 value gets you to a safe (non-root, non-system) value. If a specific value for these is needed on a given platform, then we
2005 Apr 22
0
[LLVMdev] Need help with bugpoint for codegen problem
On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote: > Ok, after pasting the output from "gccas -debug-pass=Arguments > </dev/null -o - >/dev/null" I get the following: > > bugpoint -verify -lowersetjmp -funcresolve -raiseallocs -simplifycfg > -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine > -simplifycfg -prune-eh
2005 Apr 21
0
[LLVMdev] misc CVS patches
Nope. Win32 is not (and does not pretend to be) POSIX compliant. These functions cannot be used outside of lib/System/Unix. New methods need to be added to class llvm::sys::Process. Markus F.X.J. Oberhumer wrote: > Jeff Cohen wrote: > >> Misha Brukman wrote: >> >>>> I didn't use get{u,g}id() because that's not portable - I think we >>>> need
2005 Apr 22
0
[LLVMdev] Need help with bugpoint for codegen problem
On Fri, Apr 22, 2005 at 02:14:23AM +0200, Markus F.X.J. Oberhumer wrote: > Hmm - is there some option so that bugpoint automatically runs all the > passes that are normally run by gccas and gccld ? Nope, that's not built into bugpoint, hence the procedures in the document. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
2004 Jun 23
3
[LLVMdev] weird issue with mem2reg
On Wed, Jun 23, 2004 at 03:50:09PM -0500, Patrick Meredith wrote: > MetaSplit is an anlysis I just finished writing. It doesn't alter > anything, all it does is build a set of "program instructions". For > some reason even though if I run it with any other combination of > passes I've found, anytime I run it with mem2reg I get a seg fault in > dyn_cast!
2004 Jun 23
0
[LLVMdev] weird issue with mem2reg, still
Somehow it fails with operand out of bounds when the number of operands is 2 and I am asking for the second operand. ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: <llvmdev at cs.uiuc.edu> Sent: Wednesday, June 23, 2004 4:24 PM Subject: Re: [LLVMdev] weird issue with mem2reg, should have guessed > On Wed, 23 Jun 2004, Patrick Meredith
2004 Jun 23
4
[LLVMdev] weird issue with mem2reg, should have guessed
On Wed, 23 Jun 2004, Patrick Meredith wrote: > What's different about code that's been mem2reg'd from straight front end > code, or anything that mem2reg hasn't been run on? PHINODES! Yup, front-ends generally don't produce SSA form. :) > It appears to be crashing when I try to cast a Value* that's really a > BB* (from the PHInode operands) to a User*,
2004 Jun 23
0
[LLVMdev] weird issue with mem2reg, still
void MetaSplit::handleProgramUses(Value *V){ if(!isa<BasicBlock>(V)) programValues.insert(V); if(User *U = dyn_cast<User>(V)){ User::op_iterator OB = U->op_begin(), OE = U->op_end(); for(; OB != OE; ++OB){ if(CallInst *CI = dyn_cast<CallInst>(*OB)){ Function *F = CI->getCalledFunction(); if(F == ii || F == fi || F == vi || F == di || F == ci
2005 Apr 21
5
[LLVMdev] Trailing whitespace removal (important for CVS users!)
Dear LLVMers, If you live on the bleeding edge (i.e. CVS version), please read! On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Do you really want external patches for this ? A simple Perl script > that runs on all *.h and *.cpp files, and a local commit from your > side would be much simpler. I'm in the process of doing just this as we speak. What this
2005 May 17
0
[LLVMdev] Register Allocation problem
On Mon, May 16, 2005 at 05:15:30PM -0700, John Cortes wrote: > If I use any of the regalloc parameters (local, ...) I get an error in > the LiveVariable.cpp file, in the part that I think cheaks for dead > code because a Variable didn't have a defined Instance to a Machine > instruction. > > " llc: LiveVariables.cpp:86: void >
2004 Jun 23
2
[LLVMdev] weird issue with mem2reg, still
On Wed, 23 Jun 2004, Patrick Meredith wrote: > Somehow it fails with operand out of bounds when the number of operands > is 2 and I am asking for the second operand. Second meaning operand 1. Okay, so you have something like this: if (CallInst *CI = dyn_cast<CallInst>(...)) { ... = CI->getOperand(1); } Can you send in this snippet of code, the assertion, and the
2005 Apr 21
0
[LLVMdev] Trailing whitespace removal (important for CVS users!)
On Thu, Apr 21, 2005 at 10:25:45PM +0200, Markus F.X.J. Oberhumer wrote: > while you're at this, may I also ask you to look at "indenting by tabs" > ? Some (rather few) source files have hard tabs which could be changed > to spaces in this cleanup process. OK, I'll do this in the next pass over the tree. -- Misha Brukman :: http://misha.brukman.net ::
2004 Dec 23
2
[LLVMdev] [patch] native AMD64 support
On Thu, Dec 23, 2004 at 06:42:02AM +0100, Markus F.X.J. Oberhumer wrote: > with the small patch attached below the whole llvm toolchain (llvm & > llvm-gcc) will compile and run under AMD64 Linux in native 64-bit LP64 > mode. Sounds great! I'll add it to the list of supported platforms. > This means that compilation, bytecode management and CWriter output > all work as