Mark Mitchell wrote on 10/27/06 12:25:
Aldy Hernandez wrote:
Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
Though, that is a similar global-touch-everything project, so hopefully
whatever consensus develops from tuples will carry over.
I feel the same abou
Aldy Hernandez wrote:
Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
Though, that is a similar global-touch-everything project, so hopefully
whatever consensus develops from tuples will carry over.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3
> Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
On 10/27/06, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
> My vote is to merge into mainline sooner rather than later. However, it
> is a big patch and affects just about every module in the compiler, so I
> wouldn't want to barge in without getting some consensus first.
I agree with you and Mark
Aldy Hernandez wrote on 10/27/06 09:35:
How does this sound to y'all?
Sounds good to me. I would add an additional memory savings check
between 4 and 5.
> My vote is to merge into mainline sooner rather than later. However, it
> is a big patch and affects just about every module in the compiler, so I
> wouldn't want to barge in without getting some consensus first.
I agree with you and Mark.
What I'd like to do next is:
1. Merge mainline into
Aldy Hernandez wrote on 10/26/06 10:40:
As we have hoped, every single function exhibits memory savings. Yay.
Nice!
I don't know if this merits merging into mainline, or if it's preferable to
keep plodding along and convert the rest of the tuples. What do you guys
think? Either way, I hav
On Thu, 26 Oct 2006, Aldy Hernandez wrote:
> Having analyzed about 8000 functions taken from Diego's .i sandbox (includes
> GCC files, spec files, and a potpourri of other .i files), here are the
> average memory savings:
>
> -O0:-0.243863%
> -O1:-0.977962%
> -02:-0.9
Aldy Hernandez wrote:
I don't know if this merits merging into mainline, or if it's preferable to
keep plodding along and convert the rest of the tuples. What do you guys
think? Either way, I have my work cut out for me, though I believe the
hardest part is over (FLW).
I thinking merging as
Hi folks.
Now that the branch is bootstrapping with no regressions (C and C++ anyhow),
I have run some memory benchmarks to make sure we're on the right path.
So far I have only implemented GIMPLE_MODIFY_STMT which is the tuples
counterpart of MODIFY_EXPR.
To compare memory usage, I forced a gar
10 matches
Mail list logo