On Wed, Mar 12, 2008 at 04:19, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Sure.
Thanks. Phasing out the 'tree' name is going to be a long process.
> Though gimplifier itself might end up being GIMPLE_PASS but it is
> not big deal I guess.
Both the gimplifier and the rtl expander will always ha
> On 3/9/08 7:26 AM, Jan Hubicka wrote:
>
> >compensate testsuite and documentation for the removal of RTL dump
> >letters so I would rather do that just once. Does this seem OK?
>
> Yup, thanks for doing this.
>
>
> >The patch include the read/write methods that will be just placeholders
> >o
On 3/9/08 7:26 AM, Jan Hubicka wrote:
compensate testsuite and documentation for the removal of RTL dump
letters so I would rather do that just once. Does this seem OK?
Yup, thanks for doing this.
The patch include the read/write methods that will be just placeholders
on mainline. Natural
> Jan Hubicka wrote:
>
> This looks mostly fine to me. note that i added you to pr35094 since
> this patch will resolve that issue.
>
> I guess that one of the questions that i would have is why not have
> there be a base structure for the core passmanager fields, and then a
> union that contai
Jan Hubicka wrote:
This looks mostly fine to me. note that i added you to pr35094 since
this patch will resolve that issue.
I guess that one of the questions that i would have is why not have
there be a base structure for the core passmanager fields, and then a
union that contains a one of the
Hi,
based on the discussion, this is change I would like to do to the
passmanager. I am sending the header change only first, because the
actual change will need updating all PM datastructure initializers and
compensate testsuite and documentation for the removal of RTL dump
letters so I would rat
>
> Thanks for the detailed plan. Yes, please add it to the whopr wiki.
> The only aspects that are not too clear to me are what exactly do you
> plan to do in mainline.
>
> One idea would be to do all the basic framework during stage 1 and
> leave it in mainline. I would suggest doing as much
> Currently the job to drive compilation process is implemented in
> cgraphunit and passmanager. I am leaning to plan to do as much work as
BTW for a while I think that name of cgraphunit outlived its original
meaning.
Just as historical note, it was introduced so because some bits wasn't
possibl
> I find 'analyze' for the first stage confusing. We do no analysis
> there, we just produce summary info. The analysis is actually done by
> what you call 'read'. How about some variant of:
>
> generate_summary_{function/variable}
> analyze_{function/variable}
> transform_{function/variable}
On 2/17/08 11:31 AM, Jan Hubicka wrote:
The plan would be to update passmanager first and transit main IPA passes
(inliner, constant propagation, alias analysis) on mainline. The more advanced
IPA stuff, as struct reorg can go later since it is not a showstopper for first
incarnation of whole p
Hi,
since it seems that we are getting ready with LTO, I think it is time to write
updated design document for callgraph and implementation of whole program
optimizer as outlined in Whopr document http://gcc.gnu.org/wiki/whopr
As usual, all comments or ideas are welcome ;)
Basic organization
=
11 matches
Mail list logo