Hi,
>
> Jan, wrt the optimization plan coming out of the analysis phase, and the
> various pieces of header/summary information, what do you think are the
> major pieces we need?
The cgraph used to be organized on a separate analysis, propagation and
modify stages and the passes in implemented
Diego Novillo wrote:
> On Dec 19, 2007 1:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>
>> I am hoping that in the next couple of days, Nathan and I will be able
>> to say that we have completed to work that Codesourcery/NaturalBridge
>> contracted to do with IBM. Completion means that we
On Dec 19, 2007 1:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I am hoping that in the next couple of days, Nathan and I will be able
> to say that we have completed to work that Codesourcery/NaturalBridge
> contracted to do with IBM. Completion means that we are able to compile
> and run t
On Dec 19, 2007 5:29 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> I'd be interested to hear if keeping the LTO format stable is
> something the GCC community plans to do,
I doubt it. We may end up doing it for practical reasons within a
release, but I'm not sure if it's high on anyone's priori
On Dec 19, 2007, at 2:19 PM, Tim Josling wrote:
...
http://gcc.gnu.org/projects/lto/lto.pdf
...
Was there any more about this?
I have restarted work on my COBOL front end. Based on my previous
experiences writing a GCC front end I want to have as little code as
possible in the same process
On Dec 19, 2007 5:19 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
> This means passing over a file. So I would like to understand how to
> avoid getting into political/legal trouble when doing this.
Passing over a file in what format? If you are writing a COBOL to C
translator, that will certainly
On Thu, 2007-12-13 at 08:27 -0500, Diego Novillo wrote:
> On 12/13/07 2:39 AM, Ollie Wild wrote:
>
> > The lto branch is already doing this, so presumably that discussion
> > was resolved (Maybe someone in the know should pipe up.).
>
> Yes, streaming the IL to/from disk is a resolved issue.
> ..
Diego Novillo wrote
> On 12/18/07 08:29, Jan Hubicka wrote:
>
>> Doing call graph changes should not be that hard (I was trying to keep
>> similar deisgn in mind when implementing it, even if we stepped away
>> from the plan in some cases, like reorganizing passes from vertical to
>> horisontal ord
On 12/18/07 08:29, Jan Hubicka wrote:
Doing call graph changes should not be that hard (I was trying to keep
similar deisgn in mind when implementing it, even if we stepped away
from the plan in some cases, like reorganizing passes from vertical to
horisontal order). Nearest problem I see is mer
Hi,
thanks for writting the proposal. It seems that at least in general
terms we are all in sync.
> At this point we are interested in getting feedback on the general idea.
> There is some refactoring that will be needed inside the call-graph
> manager and some aspects of the design may not even n
On Dec 13, 2007, at 5:32 AM, Diego Novillo wrote:
On 12/12/07 6:41 PM, Harvey Harrison wrote:
Any pointers to where that discussion ended up?
There was some discussion about merging LLVM and GCC a couple of
years back but nothing concrete came out of it.
The concrete thing that came out of
On 12/12/07 6:41 PM, Harvey Harrison wrote:
I'm curious how this interacts/complements with any efforts to
using the LLVM IR in LTO.
No. At least not at this moment. GCC uses its own IR (GIMPLE) as the
in-core and on-disk representation.
Any pointers to where that discussion ended up?
On 12/13/07 2:39 AM, Ollie Wild wrote:
The lto branch is already doing this, so presumably that discussion
was resolved (Maybe someone in the know should pipe up.).
Yes, streaming the IL to/from disk is a resolved issue.
I believe a stable representation is an explicit non-goal of the LTO
pr
On Wed, 12 Dec 2007, J.C. Pizarro wrote:
[...]
* "executable" means "it's from an execution to death of the e-prisoner"?
* "Indirect call promotion" means "this promotion indirectly e?"?
* "Dead variable elimination" means "elimination variable of R.I.P.s"?
* etc.
J.C.Pizarro i though
They are gaming or playing with the words of the language for Google.
If the world is global then
^^ what means "global optimizer" using the infraestructure for google? ^^.
Wow, paranoia is a new feature of J.C.'s messages.
Seriously, your future employers might search for your name in the
On Dec 12, 2007 11:14 PM, Praveen Raghavan <[EMAIL PROTECTED]> wrote:
>
> 1. Are there also plans to extend the global transformation
> capabilities. I see that the original set of global transformations is
> limited (rightfully so).
This is still at a very early design stage. Additional
transfor
On Dec 12, 2007 3:28 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
>
> Do you have any thoughts on how this approach would be able to use
> profiling information, which is very a very powerful source of
> information for producing good optimisations?
The intent is for the WPA phase to utilize profile
> While we do not have everything thought out in detail, we think we have
> enough to start doing some implementation work. I tried attaching the
> document, but the mailing list rejected it. I've uploaded it to
> http://airs.com/dnovillo/pub/whopr.pdf
>
Very very interesting proposal indeed!
I
On Wed, 2007-12-12 at 16:02 -0800, Chris Lattner wrote:
> On Dec 12, 2007, at 3:41 PM, Harvey Harrison wrote:
> >> In terms of implementation, we will likely use the LTO branch as a
> >> basis. Many of the features we will need are already being
> >> implemented
> >> in the branch, so we will kee
On Dec 12, 2007, at 3:41 PM, Harvey Harrison wrote:
In terms of implementation, we will likely use the LTO branch as a
basis. Many of the features we will need are already being
implemented
in the branch, so we will keep helping with that implementation.
I'm curious how this interacts/compl
On Wed, 2007-12-12 at 15:06 -0500, Diego Novillo wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think we
On Wed, 2007-12-12 at 15:06 -0500, Diego Novillo wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think we
Please stop spamming my gcc@gcc.gnu.org email box.
All the messages that you sent are just off-topic for this mailing list.
Please STOP sending emails.
Thank you,
Sebastian Pop
On Dec 12, 2007 4:42 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> On 2007/12/12, Jonathan Wakely <[EMAIL PROTECTED]>
On Wed, Dec 12, 2007 at 11:42:23PM +0100, J.C. Pizarro wrote:
> They are gaming or playing with the words of the language for Google.
This is absurd and off-topic. Please stop.
--
Daniel Jacobowitz
CodeSourcery
On 2007/12/12, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On 12/12/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> >
> > * The googlish user says
> > "i'm using the massive googlecc compiler that uses a lot of tons
> > of libraries
> > distributed in all the world!"
> >
> > * google sh
On 12/12/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> * The googlish user says
> "i'm using the massive googlecc compiler that uses a lot of tons
> of libraries
> distributed in all the world!"
>
> * google shutdown => googlecc compiler doesn't work, ended history, byebye.
Yet agai
On 2007/12/12, "Diego Novillo" <[EMAIL PROTECTED]> wrote:
> Over the last few weeks we (Google) have been discussing ideas on how to
> leverage the LTO work to implement a whole program optimizer that is
> both fast and scalable.
>
> While we do not have everything thought out in detail, we think w
Over the last few weeks we (Google) have been discussing ideas on how to
leverage the LTO work to implement a whole program optimizer that is
both fast and scalable.
While we do not have everything thought out in detail, we think we have
enough to start doing some implementation work. I tried a
28 matches
Mail list logo