Re: [RFC PATCH] driver: unfilter default library path [PR 104707]

han 20 bytes of saving is negligible compares to the command > line argument space of most hosts today. That's not the issue that is solved by ignoring these paths in the driver for %D/%I directives. The issue is (traditionally) that even if the startfiles sit in /usr/lib (say), yo

[RFC PATCH] driver: unfilter default library path [PR 104707]

use: 1. The less than 20 bytes of saving is negligible compares to the command line argument space of most hosts today. 2. The driver program should provide adequate information for workers There might be some hosts with such a small argv space that the 20-byte saving really matters. If so

Re: Writing automated tests for the GCC driver

Hello, Giuliano, On May 25, 2020, Giuliano Belinassi via Gcc wrote: > gcc a.c b.o -o a.out > gcc a.c b.c > gcc a.S > and so on. So if you do some radical change to the GCC driver, making > sure everything is correct get somewhat painful because you have to do > a clean boot

Re: Writing automated tests for the GCC driver

uite, that is no news at all. However they are > > > focused on the compiler (cc1*) or in libraries, and I can't find tests > > > related to the GCC driver. > > > > > > Are there tests to the GCC driver? If yes, is there any docs about how > > > to

Re: Writing automated tests for the GCC driver

nd I can't find tests > > related to the GCC driver. > > > > Are there tests to the GCC driver? If yes, is there any docs about how > > to write them? > > I think all tests to the driver eventually exercise a compiler in the end. > One obvious I can find is gc

Re: Writing automated tests for the GCC driver

On Thu, May 21, 2020 at 11:00 PM Giuliano Belinassi via Gcc wrote: > > Hi, all. > > GCC have a extensive testsuite, that is no news at all. However they are > focused on the compiler (cc1*) or in libraries, and I can't find tests > related to the GCC driver. > > Are

Writing automated tests for the GCC driver

Hi, all. GCC have a extensive testsuite, that is no news at all. However they are focused on the compiler (cc1*) or in libraries, and I can't find tests related to the GCC driver. Are there tests to the GCC driver? If yes, is there any docs about how to write them? Thank you, Giuliano.

Re: GCC 10: Add driver options -mbranches-within-32B-boundaries and -malign-branch* for x86

e mitigation of a serious CPU bug > (https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf > and see the news around this). > > It seems that there is still no GCC driver option yet. Currently users > are expected to use: &g

GCC 10: Add driver options -mbranches-within-32B-boundaries and -malign-branch* for x86

t/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf and see the news around this). It seems that there is still no GCC driver option yet. Currently users are expected to use: -Xassembler -mbranches-within-32B-boundaries -Wa,-mbranches-within-32B-boundaries I th

LVM 2.02.168 2016-11-30 libary 1.02.137 Driver Versuon 4.35.0 :/#

RE: GCC driver to "Compile twice, score the assembly, choose the best"?

> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > Of Ian Bolton > Sent: 15 May 2014 12:47 > To: gcc@gcc.gnu.org > Subject: GCC driver to "Compile twice, score the assembly, choose the > best"? > >

Re: GCC driver to "Compile twice, score the assembly, choose the best"?

"Ian Bolton" writes: > I was wondering if the "gcc" driver could be made to invoke > "cc1" twice, with different flags, and then just keep the > better of the two .s files that comes out? How do you define "better"? Andreas. -- Andreas Schw

RE: GCC driver to "Compile twice, score the assembly, choose the best"?

Thanks for the quick response. > On Thu, May 15, 2014 at 1:46 PM, Ian Bolton wrote: > > Hi, fellow GCC developers! > > > > I was wondering if the "gcc" driver could be made to invoke > > "cc1" twice, with different flags, and then just keep th

Re: GCC driver to "Compile twice, score the assembly, choose the best"?

On Thu, May 15, 2014 at 1:46 PM, Ian Bolton wrote: > Hi, fellow GCC developers! > > I was wondering if the "gcc" driver could be made to invoke > "cc1" twice, with different flags, and then just keep the > better of the two .s files that comes out? I'd

GCC driver to "Compile twice, score the assembly, choose the best"?

Hi, fellow GCC developers! I was wondering if the "gcc" driver could be made to invoke "cc1" twice, with different flags, and then just keep the better of the two .s files that comes out? I'm sure this is not a new idea, but I'm not aware of anything being done i

DRIVER

I NEED A DRIVER FOR MY WIFE

Re: [Bug driver/49858] lost ability to use driver for external language support?

; > Is there a mechanism by which the driver can be informed of options that it > > should allow in this situation, given that the list of these options is not > > known at the time the driver is compiled? > > No. By design there is now a structured notion of options shared b

Re: Using -save-temps and @file should also save the intermediate @file used by the driver?

On Tue, May 10, 2011 at 10:28 AM, Ian Bolton wrote: > Does anyone have some thoughts they'd like to share on this: > > "When you compile anything using @file support, the driver assumes @file > (at_file_supplied is true) is allowed and may pass options to the linker via >

Using -save-temps and @file should also save the intermediate @file used by the driver?

Does anyone have some thoughts they'd like to share on this: "When you compile anything using @file support, the driver assumes @file (at_file_supplied is true) is allowed and may pass options to the linker via @file using a *temporary* file. When -save-temps is also used, the tempo

Re: Behavior change of driver on multiple input assembly files

On 01/04/2011 07:33 AM, Ian Lance Taylor wrote: On Thu, Dec 30, 2010 at 9:07 PM, Jie Zhang wrote: For a minimal fix, I propose to change combinable fields of assembly languages in default_compilers[] to 0. See the attached patch "gcc-not-combine-assembly-inputs.diff". I don't know why the comb

Re: Behavior change of driver on multiple input assembly files

On Thu, Dec 30, 2010 at 9:07 PM, Jie Zhang wrote: > For a minimal fix, I propose to change combinable fields of assembly > languages in default_compilers[] to 0. See the attached patch > "gcc-not-combine-assembly-inputs.diff". I don't know why the combinable > fields were set to 1 when --combine

Re: Behavior change of driver on multiple input assembly files

Richard Guenther writes: > On Sun, Jan 2, 2011 at 10:18 PM, Ian Lance Taylor wrote: >> No, it is not.  All .go input files must be passed to go1 at once. >> H.J.'s patch has indeed broken gccgo. > > Interesting. Do we have a testcase that is now broken? It seems to me > that gcgo should force

Re: Behavior change of driver on multiple input assembly files

> >>>> > >>>> I wonder why @assembler has 1 for combinable?  It seems to have been set > >>>> to 1 when the combinable field was added in 2004-04-05 with -combine. > >>>> Now that -combine has been removed, if the combinable field for >

Re: Behavior change of driver on multiple input assembly files

t.  The difference is that @c has 0 for the combinable >>>>> field, and @assembler has 1.  Before H.J.'s change, this worked >>>>>    gcc -c -o f.o f1.s f2.s >>>>> After his change, it does not.  That is probably not a big deal. >>>>

Re: Behavior change of driver on multiple input assembly files

gt;>>    gcc -c -o f.o f1.s f2.s >>>> After his change, it does not.  That is probably not a big deal. >>>> >>>> I wonder why @assembler has 1 for combinable?  It seems to have been set >>>> to 1 when the combinable field was added in 2004-04-05 with -

Re: Behavior change of driver on multiple input assembly files

;> I wonder why @assembler has 1 for combinable?  It seems to have been set >>> to 1 when the combinable field was added in 2004-04-05 with -combine. >>> Now that -combine has been removed, if the combinable field for >>> @assembler were 0, it seems to me that H.J.'s

Re: Behavior change of driver on multiple input assembly files

;> I wonder why @assembler has 1 for combinable?  It seems to have been set >>> to 1 when the combinable field was added in 2004-04-05 with -combine. >>> Now that -combine has been removed, if the combinable field for >>> @assembler were 0, it seems to me that H.J.'s

Re: Behavior change of driver on multiple input assembly files

n 2004-04-05 with -combine. >> Now that -combine has been removed, if the combinable field for >> @assembler were 0, it seems to me that H.J.'s problem would also be >> fixed.  And it seems to me that it should be 0. >> >> >>>> Also, right now the gccgo driver

Re: Behavior change of driver on multiple input assembly files

On Sun, Jan 2, 2011 at 2:40 PM, Richard Guenther wrote: > > Interesting.  Do we have a testcase that is now broken?  It seems to me See: http://gcc.gnu.org/ml/gcc-regression/2011-01/msg00011.html -- H.J.

Re: Behavior change of driver on multiple input assembly files

oblem would also be > fixed.  And it seems to me that it should be 0. That was another proposed patch. I wondered if that would break gcc -o t -flto -flto-partition=none t1.c t2.c -save-temps -v (repeating the generation of t1.s, we overwrite this with lto1 output ...) gcc -o t -flto -flto

Re: Behavior change of driver on multiple input assembly files

ot a big deal. > > I wonder why @assembler has 1 for combinable?  It seems to have been set > to 1 when the combinable field was added in 2004-04-05 with -combine. > Now that -combine has been removed, if the combinable field for > @assembler were 0, it seems to me that H.J.&#

Re: Behavior change of driver on multiple input assembly files

On Sun, 02 Jan 2011 13:18:22 -0800 Ian Lance Taylor wrote: > No, it is not. All .go input files must be passed to go1 at once. > H.J.'s patch has indeed broken gccgo. I can confirm that. I just tried to svn merge trunk 168407 into the GCC MELT branch (which, appart from the MELT stuff, is exac

Re: Behavior change of driver on multiple input assembly files

04-05 with -combine. Now that -combine has been removed, if the combinable field for @assembler were 0, it seems to me that H.J.'s problem would also be fixed. And it seems to me that it should be 0. >> Also, right now the gccgo driver depends on the -o behaviour to combine >>

Re: Behavior change of driver on multiple input assembly files

On Sun, Jan 2, 2011 at 12:24 PM, Ian Lance Taylor wrote: > Richard Guenther writes: > >> Your small patch removing have_o || is ok I guess. > > Wait.  That will change the behaviour of >    gcc -o foo.o -c f1.c f2.c f3.c > Is that what we want? > No. We always do [i...@gnu-1 gcc]$ gcc -o foo.o

Re: Behavior change of driver on multiple input assembly files

hink so. Most of the combine handling was removed by the patch that caused the regression, so -o and -c doesn't combine anymore (with multiple sources). > Also, right now the gccgo driver depends on the -o behaviour to combine > inputs.  If that changes, the driver will need to provide so

Re: Behavior change of driver on multiple input assembly files

Richard Guenther writes: > Your small patch removing have_o || is ok I guess. Wait. That will change the behaviour of gcc -o foo.o -c f1.c f2.c f3.c Is that what we want? Also, right now the gccgo driver depends on the -o behaviour to combine inputs. If that changes, the driver will n

Re: Behavior change of driver on multiple input assembly files

9:40 PM, H.J. Lu wrote: >>>>> On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang wrote: >>>>>> On 12/31/2010 01:07 PM, Jie Zhang wrote: >>>>>>> >>>>>>> I just found a behavior change of driver on multiple input assembly >>>

Re: Behavior change of driver on multiple input assembly files

ie Zhang wrote: >>>>> On 12/31/2010 01:07 PM, Jie Zhang wrote: >>>>>> >>>>>> I just found a behavior change of driver on multiple input assembly >>>>>> files. Previously (before r164357), for the command line >>>&

Re: Behavior change of driver on multiple input assembly files

t;>>>> >>>>> I just found a behavior change of driver on multiple input assembly >>>>> files. Previously (before r164357), for the command line >>>>> >>>>> gcc -o t t1.s t2.s >>>>> >>>>> , the dri

Re: Behavior change of driver on multiple input assembly files

t;>>>> >>>>> I just found a behavior change of driver on multiple input assembly >>>>> files. Previously (before r164357), for the command line >>>>> >>>>> gcc -o t t1.s t2.s >>>>> >>>>> , the dri

Re: Behavior change of driver on multiple input assembly files

On Sun, Jan 2, 2011 at 8:03 AM, Richard Guenther wrote: > On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu wrote: >> On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang wrote: >>> On 12/31/2010 01:07 PM, Jie Zhang wrote: >>>> >>>> I just found a behavior change of dr

Re: Behavior change of driver on multiple input assembly files

On Fri, Dec 31, 2010 at 9:40 PM, H.J. Lu wrote: > On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang wrote: >> On 12/31/2010 01:07 PM, Jie Zhang wrote: >>> >>> I just found a behavior change of driver on multiple input assembly >>> files. Previously (before r164357),

Re: Behavior change of driver on multiple input assembly files

On Fri, Dec 31, 2010 at 5:08 AM, Jie Zhang wrote: > On 12/31/2010 01:07 PM, Jie Zhang wrote: >> >> I just found a behavior change of driver on multiple input assembly >> files. Previously (before r164357), for the command line >> >> gcc -o t t1.s t2.s >> &g

Re: Behavior change of driver on multiple input assembly files

On 12/31/2010 01:07 PM, Jie Zhang wrote: I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only

Behavior change of driver on multiple input assembly files

I just found a behavior change of driver on multiple input assembly files. Previously (before r164357), for the command line gcc -o t t1.s t2.s , the driver will call assembler twice, once for t1.s and once for t2.s. After r164357, the driver will only call assembler once for t1.s and t2.s

Joseph Myers appointed GCC driver reviewer

I am pleased to announce that the GCC Steering Committee has appointed Joseph Myers as GCC driver reviewer. Please join me in congratulating Joseph on his new role. Joseph, please update your listing in the MAINTAINERS file. Happy hacking! David

Re: need help on GCC driver

Vikram KS wrote: So in the back-end there are driver options that will help me to invoke the existing tool-chain through GCC driver. But the assembler takes only .sl extensions. I tried to replace the .s extension with .sl extension. But by default the cc1 will have some options passed from the

Re: need help on GCC driver

On Thu, Jul 30, 2009 at 8:14 PM, Basile STARYNKEVITCH wrote: > > Vikram KS wrote: >> >> Hi, >> >> I have some question on gcc driver. > > You really should give more context. Are you doing cross-compilation? Are you > patching the GCC sources? Why do you

Re: need help on GCC driver

Vikram KS wrote: Hi, I have some question on gcc driver. You really should give more context. Are you doing cross-compilation? Are you patching the GCC sources? Why do you want to generate a *.sl file? What are your host & target systems? Whenever we invoke gcc, it'll pass som

need help on GCC driver

Hi, I have some question on gcc driver. Whenever we invoke gcc, it'll pass some default options to the compiler, assembler linker etc. But if i dont want to pass all these default options but only some of them, what should i do? For eg: gcc will pass the following option to cc1 /usr/li

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

"Cary Coutant" <[EMAIL PROTECTED]> writes: >> * GOLD_VERSION should perhaps say something about the format of the >> string. > > OK. What would be reasonable to say here? Just a string of the form > "n.m"? Is it reasonable to require that later versions are lexically > greater than earlier versio

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

> On the "claim file", can you also pass the "file" size in the case it > is inside an archive? Good idea. Will do. -cary

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

> * "End of first pass" may be a little gold specific. Perhaps it > should be called something like "after all input files have been > seen." Sure. It seems to me that the pass 1, middle, pass 2 breakdown is pretty common for linkers, though perhaps not universal. I'll find a better name (I was

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

On Thu, Jul 03, 2008 at 09:48:11PM -0700, Ian Lance Taylor wrote: > * The linker does normally copy unrecognized sections with the > SHF_ALLOC bit clear to the output file. It doesn't allocate address > space for them, but it does copy them. I think this follows the ELF > ABI. I don't know

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

> I've updated the WHOPR Driver wiki page with our latest thoughts on > the plug-in interface: > > http://gcc.gnu.org/wiki/whopr/driver Very nice! Just one comment: On the "claim file", can you also pass the "file" size in the case it is inside an archive?

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

"Cary Coutant" <[EMAIL PROTECTED]> writes: >> 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 ca

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

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

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

On Jun 5, 2008, at 6:18 PM, Ian Lance Taylor wrote: How does the linker tell LTO that a symbol may be inlined, but must also be externally visible? The linker just tells LTO which symbols must remain. The LTO engine is free to inline anything that would improve codegen, with the exception t

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

Chris Lattner <[EMAIL PROTECTED]> writes: > On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote: > >> Nick Kledzik <[EMAIL PROTECTED]> writes: >> How does the linker tell LTO that a symbol may be inlined, but must also be externally visible? >>> The linker just tells LTO which symbols mus

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

On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote: Nick Kledzik <[EMAIL PROTECTED]> writes: How does the linker tell LTO that a symbol may be inlined, but must also be externally visible? The linker just tells LTO which symbols must remain. The LTO engine is free to inline anything that wo

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

Nick Kledzik <[EMAIL PROTECTED]> writes: >> How does the linker tell LTO that a symbol may be inlined, but must >> also be externally visible? > The linker just tells LTO which symbols must remain. The LTO engine > is free to inline anything that would improve codegen, with the > exception > that

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

On Jun 5, 2008, at 10:43 AM, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: LLVM LTO handles this by marking symbols "internal" (aka static, aka not TREE_PUBLIC, whatever) when the symbol is not visible outside the LTO scope. This allows the optimizers to go crazy and hack

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

Chris Lattner <[EMAIL PROTECTED]> writes: > LLVM LTO handles this by marking symbols "internal" (aka static, aka > not TREE_PUBLIC, whatever) when the symbol is not visible outside the > LTO scope. This allows the optimizers to go crazy and hack away at > the symbols, but only when safe. How doe

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

On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote: "Rafael Espindola" <[EMAIL PROTECTED]> writes: Interesting. The use of lto_codegen_add_must_preserve_symbol is kind of the opposite of what I had understood. What do you do in this case: a.o: IL file that contains a reference to "f" b.o:

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

On Thu, Jun 5, 2008 at 11:09, Jan Hubicka <[EMAIL PROTECTED]> wrote: > I think one problem is that both repackaging and cherry picking as > described is very centric about application on inlining. No, that's simply the main application for the initial implementation. Any other summary-based tran

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

Hi, I am jumping in somewhat late, as yesterday I was on meetings without internet access. (and I probably will be offline again tomorrow) I think that in basic terms we all mostly agree (we want to implement optimization scheme that does not get everything into memory, we want to parallelize the

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

"Rafael Espindola" <[EMAIL PROTECTED]> writes: > Interesting. The use of lto_codegen_add_must_preserve_symbol is kind > of the opposite of what I had understood. What do you do in this case: > > a.o: IL file that contains a reference to "f" > b.o: IL file that has a weak def of "f" > > There is no

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

>> In ELF you have to think about symbol overriding. Let's say you link >> a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong >> definition. c.o has a weak definition. a.o and c.o have LTO >> information, b.o does not. ELF requires that a.o call the symbol from >> b.o, not the sym

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

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: [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.

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: [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: [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: [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

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

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 n

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.

  1   2   >