similar to: [LLVMdev] Optional Target Builds

On Thu, 21 Apr 2005, Reid Spencer wrote: > With Misha's changes requiring a total rebuild, I've been reminded how > long the targets take to build. Now that there are more of them and in > most cases I really don't care about n-1 of them, I'm wondering if its > time to have configure allow optional compilation for them. > > I would like to suggest: > > 1.

On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > On Thu, 21 Apr 2005, Reid Spencer wrote: > > With Misha's changes requiring a total rebuild, I've been reminded how > > long the targets take to build. Now that there are more of them and in > > most cases I really don't care about n-1 of them, I'm wondering if its > > time to have configure allow

On Thu, 2005-04-21 at 23:58 -0700, Reid Spencer wrote: > On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > > On Thu, 21 Apr 2005, Reid Spencer wrote: > > > With Misha's changes requiring a total rebuild, I've been reminded how > > > long the targets take to build. Now that there are more of them and in > > > most cases I really don't care

On Thu, 2005-21-04 at 19:43 -0700, Reid Spencer wrote: > In case it wasn't obvious from Misha's answer, the main reason for > doing this is speed. RTTI is not very quick. Right. This is why I was somewhat suprized to see the "isa" facilities included in LLVM without also disabling rtti. It will reduce the memory footprint a fair bit if you do disable it, at least based on

On Thu, 2005-04-21 at 23:58 -0700, Reid Spencer wrote: > On Fri, 2005-04-22 at 00:33 -0500, Chris Lattner wrote: > > On Thu, 21 Apr 2005, Reid Spencer wrote: > > > With Misha's changes requiring a total rebuild, I've been reminded how > > > long the targets take to build. Now that there are more of them and in > > > most cases I really don't care

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

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 >

On Fri, 22 Apr 2005, Al Stone wrote: >> Actually, the options have to be expressed as "enable-something" so >> I've opted for "--enable-target-this" to enable just the $host target. >> if you specify --disable-target-this (the default) then you get >> whatever platforms you specify with --enable-target-{targetname} >> >> Does that make

Why not put all this into a pre-commit filter in CVS and be done with it? We'd never be bothered with it again as it would never be committed again. Reid. On Thu, 2005-04-21 at 15:11 -0500, Misha Brukman wrote: > 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:

On Fri, 2005-04-22 at 08:15 -0500, Andrew Lenharth wrote: > -enable-targets=x86,alpha,sparcv9 > -link-targets=alpha,host > > Valid options for both are: > the names of the targets > host > all As others have agreed, this is a much better approach than the one I was thinking of. Its harder to parse in the configure script, but I can probably find a way to do it. >

On Fri, Apr 22, 2005 at 08:54:07AM -0700, Reid Spencer wrote: > There has been some debate about the default value. I tend to agree > with Chris on this. The default should be "all" so that everything > gets tested by default. More sophisticated users can limit the targets > that are built by merely typing -enable-targets=host on the configure > line; not a big deal in my

Hi, How do I setup multiple password protected iSCSI targets on Linux? I know that mounting a password protected iSCSI target requires modify these records with the appropriate values: node.session.auth.username = My_ISCSI_USR_NAME node.session.auth.password = MyPassword discovery.sendtargets.auth.username = My_ISCSI_USR_NAME discovery.sendtargets.auth.password = MyPassword But, now I need

Evan, In case it wasn't obvious from Misha's answer, the main reason for doing this is speed. RTTI is not very quick. Since LLVM is well contained, there are no IR classes that LLVM doesn't know about it. Using dynamic_cast is really only warranted when blending libraries together that have inheritance relationships between them that aren't known in one or more of the libraries.

On Fri, 2005-04-22 at 10:18 -0500, Chris Lattner wrote: > On Fri, 22 Apr 2005, Al Stone wrote: > >> Actually, the options have to be expressed as "enable-something" so > >> I've opted for "--enable-target-this" to enable just the $host target. > >> if you specify --disable-target-this (the default) then you get > >> whatever platforms

Dear, im using mingw and as under win xp. "Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. " im dont understand. What is pr492? (url) and where is the fix for

I see a bunch of definitions scattered throughout LLVM, and I could not find good documentation on them. I don't understand why they exist when LLVM is being compiled with RTTI enabled. It seems to me that: isa<T>(x) is a substitute for (dynamic_cast<T>(x) != NULL) and there are some other similar casting tools defined in Casting.h. Why should I use these instead of C++'s

On Wed, Apr 27, 2005 at 10:28:30PM +0200, Thomas Lodenscheidt wrote: > im dont understand. What is pr492? (url) http://llvm.cs.uiuc.edu/PR492 -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

Hi, I'm a cs326 student that uses LLVM for our MP. While some of the COOL program can be run seamlessly, I get the following assertion error for many of them. lli: Pass.cpp:95: bool llvm::FunctionPassManager::run(llvm::Function&): >> Assertion `(&F == mF) && "ModuleProvider does not contain this >> function!"' failed. >> >> It seems

Hi, I'm working on bug 122, consolidating the interface to the SymbolTable class. In doing so, I found the function below which traverses the symbol table but apparently unnecessarily. Before I remove the traversal, I thought I better check with you guys. Posted this to the list because it looks like _everyone_ has edited this file :) In the code below, the IOB variable is the only thing in

I mis-stated what I think should be deleted. The block of code from "GlobalVariable *IOB = 0;" to the end of the loop should be delted because the only effect the loop has is on the IOB variable and that variable is never used after the loop. Reid. On Tue, 2004-05-11 at 18:14, Reid Spencer wrote: > Hi, > > I'm working on bug 122, consolidating the interface to the