Re: [whopr] plugin interface design

On Jun 4, 2008, at 10:39 PM, Ian Lance Taylor wrote: Devang Patel <[EMAIL PROTECTED]> writes: If the optimizer can handle the symbol versioning case when one definition with version is defined in the same source file as the reference then you don't need new API. For example, a.o : refers to S

Re: [whopr] Design/implementation alternatives for the driver and WPA

Nick Kledzik <[EMAIL PROTECTED]> writes: > In this case S is a regular symbol. So the previous trick won't > work. Probably > the best solution would be to add a new lto_ API to tell the LTO > engine to > ignore a definition is already has. It would make more sense to use > this > new API in t

Re: [whopr] Design/implementation alternatives for the driver and WPA

[ trimming the CC list ] Devang Patel <[EMAIL PROTECTED]> writes: > If the optimizer can handle the symbol versioning case when one > definition with version is defined in the same source file as the > reference then you don't need new API. > > For example, > > a.o : refers to S and defines S at

How to insert nops

Hello all, For the big endian 16bit target that i am porting to gcc 4.1.2 a nop is needed after a load instruction if the destination register of the load instruction is used as the source in the next instruction. So load R0, R3[2] add R2, R0 needs a nop inserted in between the instructions. I h

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 6:09 PM, Nick Kledzik wrote: On Jun 4, 2008, at 5:39 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: I don't claim our current implementation is bug free,

Re: [MELT] branch Melt- bootstrapped & questions...

On Tue, Jun 3, 2008 at 5:41 AM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Hello All, > > See http://gcc.gnu.org/wiki/MiddleEndLispTranslator for MELT > > The MELT branch bootstrapped, in the sense that the Lisp compiler is able to > compile itself to C code. It is not the bootstrap in the u

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 5:39 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: I don't claim our current implementation is bug free, but the lto interface matches the Apple linker inte

Re: [whopr] Design/implementation alternatives for the driver and WPA

Nick Kledzik <[EMAIL PROTECTED]> writes: > On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote: >> Nick Kledzik <[EMAIL PROTECTED]> writes: >> >>> I don't claim our current implementation is bug free, but the lto >>> interface >>> matches the Apple linker internal model, so we don't expect and have

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: I don't claim our current implementation is bug free, but the lto interface matches the Apple linker internal model, so we don't expect and have not encountered any problems mixing mach-o and llvm bitc

Re: [whopr] Design/implementation alternatives for the driver and WPA

Nick Kledzik <[EMAIL PROTECTED]> writes: > I don't claim our current implementation is bug free, but the lto > interface > matches the Apple linker internal model, so we don't expect and have > not encountered any problems mixing mach-o and llvm bitcode files. Hmmm, OK, how about this example: a

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Wed, Jun 4, 2008 at 15:33, Chris Lattner <[EMAIL PROTECTED]> wrote: > Right, I understand that you design "stacks" on LTO. It just seems strange > to work on the advanced stuff before the basic GCC LTO stuff is close to > being useful. Not at all. We are working on both fronts. Diego.

gcc-4.2-20080604 is now available

Snapshot gcc-4.2-20080604 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080604/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Development process for i386 machine descriptions

Hello, I'm a new developer to GCC and have been tasked with building a machine description for an x86 processor. I have documentation regarding the pipeline stages, instruction latency, and even a number of special case optimization possibilities. I have been adding small changes to i386.

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 1:45 PM, Ian Lance Taylor wrote: The result is that the plugin is required to do symbol resolution itself. This 1) loses one of the benefits of having the linker around; 2) will yield incorrect results when some non- LTO object is linked in between LTO objects but redefine

Re: [MELT] branch Melt- bootstrapped & questions...

> "Basile" == Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: Basile> 1. Should I avoid committing warm-basilys-0.c frequently to Basile> lower the Subversion server disk consumption? I don't know the answer to this one. Basile> 2. I cannot figure out if tbhe GCC bugzilla can be used for wo

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Wed, Jun 4, 2008 at 16:03, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > However this was not the point of my mail. The point of my mail was whopr's > design that seems to basically sacrifice almost all interprocedural analysis > and transformation except for inlining in order to scale so as to b

Re: [whopr] Design/implementation alternatives for the driver and WPA

Nick Kledzik <[EMAIL PROTECTED]> writes: > On Jun 4, 2008, at 12:44 PM, Ian Lance Taylor wrote: >> Chris Lattner <[EMAIL PROTECTED]> writes: >> * The return value of lto_module_get_symbol_attributes is not defined. >>> >>> Ah, sorry about that. Most of the details are actually in the pu

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 12:44 PM, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: * The return value of lto_module_get_symbol_attributes is not defined. Ah, sorry about that. Most of the details are actually in the public header. The result of this function is a 'lto_symbol_at

Re: sshproxy.sourceware.org down?

Uros Bizjak <[EMAIL PROTECTED]> writes: > Is there something wrong with the connection to > sshproxy.sourceware.org [1]? The host is unreachable for a couple of > days. I had to change the IP address. It should be working at the new IP address (64.13.131.149). You can wait a few more hours, or

Re: [whopr] Design/implementation alternatives for the driver and WPA

Kenneth Zadeck <[EMAIL PROTECTED]> writes: > I do not want to imply that google's needs are not real and that they > should not use gcc to fulfill them. I only want to raise the point > that whopr is at one end of a spectrum in which REAL tradeoffs are > being made in the quality of compilation

Re: [whopr] Design/implementation alternatives for the driver and WPA

Ollie Wild wrote: On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner <[EMAIL PROTECTED] > wrote: 1) start with all code in memory and see how far you can get. It seems that on reasonable developer machines (e.g. 2GB memory) that we can handle C programs on the

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Wed, Jun 4, 2008 at 12:33 PM, Chris Lattner <[EMAIL PROTECTED]> wrote: > > Right, I understand that you design "stacks" on LTO. It just seems strange > to work on the advanced stuff before the basic GCC LTO stuff is close to > being useful. To some degree, we're scratching our own itch here.

Re: [lto] Streaming out language-specific DECL/TYPEs

Jan Hubicka wrote: Sure if it works, we should be lowering the types during gimplification so we don't need to store all this in memory... But C++ FE still use its local data later in stuff like thunks, but we will need to cgraphize them anyway. I agree. The only use of language-specific DECL

Re: [whopr] Design/implementation alternatives for the driver and WPA

Chris Lattner <[EMAIL PROTECTED]> writes: >> * The return value of lto_module_get_symbol_attributes is not >> defined. > > Ah, sorry about that. Most of the details are actually in the public > header. The result of this function is a 'lto_symbol_attributes' > bitmask. This should be more usef

Fwd: [whopr] Design/implementation alternatives for the driver and WPA

Reposting this as well. Ollie On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner <[EMAIL PROTECTED]> wrote: > > 1) start with all code in memory and see how far you can get. It seems that > on reasonable developer machines (e.g. 2GB memory) that we can handle C > programs on the order of a million

Fwd: [whopr] Design/implementation alternatives for the driver and WPA

Reposting to the gcc list since my first email got bounced. Ollie On Tue, Jun 3, 2008 at 7:26 PM, Chris Lattner <[EMAIL PROTECTED]> wrote: > This is a very interesting design, and a very nice evolution from the > previous proposal. I'm not completely clear on the difference between LTO > an

Re: [whopr] Design/implementation alternatives for the driver and WPA

Also, returning a single object file restricts the possibilities. The design of WHOPR, as I understand it, permits creating several different object files in parallel based on a fast analysis of which code should be compiled together. When the linker supports concurrent linking, it will be

sshproxy.sourceware.org down?

Hello! Is there something wrong with the connection to sshproxy.sourceware.org [1]? The host is unreachable for a couple of days. [1] http://gcc.gnu.org/ml/gcc/2005-10/msg00475.html Uros.

Re: [whopr] Design/implementation alternatives for the driver and WPA

Kenneth Zadeck <[EMAIL PROTECTED]> writes: > In particular, there are a lot of decisions that are being made in > whopr to support very large applications that are done so at the > expense of compiling modest and even large applications. I do not > necessarily disagree with these decisions, but I

Is this a typo in setup_incoming_varargs_64?

Hi, setup_incoming_varargs_64 in i386.c has /* Compute address to jump to : label - 5*eax + nnamed_sse_arguments*5 */ tmp_reg = gen_reg_rtx (Pmode); nsse_reg = gen_reg_rtx (Pmode); emit_insn (gen_zero_extendqidi2 (nsse_reg, gen_rtx_REG (QImode, AX_REG))); e

MIrror

Hello, Karl Berry (GNU webmaster) ask me contact with you about new GCC mirror. It's up already. Please check http://gcc.releasenotes.org/ Let me know if you need something else. Thanks. Alex Korolev [EMAIL PROTECTED]

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Wed, Jun 4, 2008 at 12:50, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > While i agree that some form of lto needs to support monster apps, that > should not inhibit us from supporting transformations or models of > compilation that are only practical with 100k line programs. Of course not. Tha

Re: [whopr] Design/implementation alternatives for the driver and WPA

Ian Lance Taylor wrote: Kenneth Zadeck <[EMAIL PROTECTED]> writes: I think that one thing that the gcc community should understand is that to a great extent whopr is a google thing. All of the documents are drafted by google people, in meetings that are only open to google people and it is

Re: [whopr] Design/implementation alternatives for the driver and WPA

> Hey Rafael! Hello! >> *) Plugins could have other uses and the naming used on the LLVM LTO >> interface is LTO specific. > > The LLVM interface uses an lto_ prefix. This interface is used by nm/ar/etc > as well as the linker. Is there something specific about lto_ that is bad? > http://llvm.or

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 9:29 AM, Chris Lattner wrote: Suppose the linker is invoked on a sequence of object files, some with with LTO information, some without, all interspersed. Suppose some symbols are defined in multiple .o files, through the use of common symbols, weak symbols, and/or section g

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 12:27 AM, Rafael Espindola wrote: Is there a specific reason you don't use the LLVM LTO interface? It seems to be roughly the same as your proposed interface: a) it has a simple C interface like your proposed one b) it is already implemented in one system linker (Apple's)

Re: [whopr] Design/implementation alternatives for the driver and WPA

Diego Novillo wrote: We've started working on the driver and WPA components for whopr. These are some of our initial thoughts and implementation strategy. I have linked these to the WHOPR page as well. I'm hoping we can discuss these at the Summit BoF, so I'm posting them now to start the discu

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 7:22 AM, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: Is there a specific reason you don't use the LLVM LTO interface? It seems to be roughly the same as your proposed interface: a) it has a simple C interface like your proposed one b) it is already impl

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Jun 4, 2008, at 8:27 AM, Kenneth Zadeck wrote: It is certainly not going to be possible to do this for all ipa passes, in particular any pass that requires the function body to be reanalyzed as part of the analysis pass will not be done, or will be degraded so that it does not use this

Re: [whopr] Design/implementation alternatives for the driver and WPA

Kenneth Zadeck <[EMAIL PROTECTED]> writes: > I think that one thing that the gcc community should understand is > that to a great extent whopr is a google thing. All of the documents > are drafted by google people, in meetings that are only open to google > people and it is only after these docu

Re: [whopr] Design/implementation alternatives for the driver and WPA

2008/6/4 Ian Lance Taylor <[EMAIL PROTECTED]>: > Diego Novillo <[EMAIL PROTECTED]> writes: > > I have a feeling that the comments I wrote within Google about the > linker interface were lost. I am going to try to recreate them here. I have added them to the gcc wiki. I have also removed some of

Re: [whopr] Design/implementation alternatives for the driver and WPA

Diego Novillo wrote: On Tue, Jun 3, 2008 at 22:26, Chris Lattner <[EMAIL PROTECTED]> wrote: and whopr here. Is LTO the mode "normal people" will use, and whopr is the mode where "people with huge clusters" will use? Will LTO/whopr support useful optimization on common multicore machines?

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Wed, Jun 4, 2008 at 10:44, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > I have a feeling that the comments I wrote within Google about the > linker interface were lost. I am going to try to recreate them here. Sorry. I should've been more careful when I transcribed it over. Diego.

Re: How to reserve an Elf e_machine value

On Tue, Jun 03, 2008 at 08:46:44AM -0700, Stephen Andieta wrote: > > I am working on a compiler kit for an in-house processor that uses Elf as > object file format. Since this compiler will be released to external > customers, I need to reserve an 'official' e_machine value for this > processor. S

Re: [whopr] Design/implementation alternatives for the driver and WPA

Diego Novillo <[EMAIL PROTECTED]> writes: I have a feeling that the comments I wrote within Google about the linker interface were lost. I am going to try to recreate them here. > The linker, upon start, examines a configuration file at a known > location relative to its own location. If this f

Re: [whopr] Design/implementation alternatives for the driver and WPA

Chris Lattner <[EMAIL PROTECTED]> writes: > Is there a specific reason you don't use the LLVM LTO interface? It > seems to be roughly the same as your proposed interface: > > a) it has a simple C interface like your proposed one > b) it is already implemented in one system linker (Apple's), so GC

Re: [whopr] Design/implementation alternatives for the driver and WPA

On Tue, Jun 3, 2008 at 22:26, Chris Lattner <[EMAIL PROTECTED]> wrote: > and whopr here. Is LTO the mode "normal people" will use, and whopr is the > mode where "people with huge clusters" will use? Will LTO/whopr support > useful optimization on common multicore machines? As Ollie said, WHOPR

MULTILIB_OSDIRNAMES trouble

Hello, I'm experimenting with a hardware dfp libgcc_s for S/390. The target is to have an additional variant of that lib built using the multilib machinery. Regarding this I'm wondering how to set MULTILIB_OSDIRNAMES correctly. This variable is usually set in a makefile fragment in the back end

Re: why 6Gb RAM not enough to compile a 14Mb source [MELT]?

On Wed, Jun 4, 2008 at 8:31 AM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Hello All, > > my MELT branch http://gcc.gnu.org/wiki/MiddleEndLispTranslator has a big > source file in it warm-basilys-0.c. It is "self" generated, about 14Mbytes & > almost 280KLOC (in rev136334). It ends with a bi

Re: [whopr] Design/implementation alternatives for the driver and WPA

> Is there a specific reason you don't use the LLVM LTO interface? It seems > to be roughly the same as your proposed interface: > > a) it has a simple C interface like your proposed one > b) it is already implemented in one system linker (Apple's), so GCC would > just provide its own linker plugi