Re: memory benchmark of tuples branch
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 you go is fine, in principle. Every little bit helps. My only concern would be whether you'll disrupt other large-scale projects that might find global changes hard to handle. I'd suggest posting your patch and seeing if anyone makes unhappy sounds. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: memory benchmark of tuples branch
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.968168% > > As we have hoped, every single function exhibits memory savings. Yay. When this goes in, please don't by shy and update gcc-4.3/changes.html; and potentially submit a news entry for our main page as well -- we've got way too few there... :-) Gerald
Re: memory benchmark of tuples branch
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 have my work cut out for me, though I believe the hardest part is over (FLW). 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. As for the rest of the conversion, I don't think there are many changes left that are as invasive as this one. Mostly global search and replace, but it's been a few weeks since I looked at the code. I'm hoping we can extend the rest of the changes into late Stage1 and Stage2, but we can see about that as we go.
Re: memory benchmark of tuples branch
> 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 the branch to make sure there are no snafus. 2. Post the patch so folks can look at it while I do 3 & 4: 3. Attack the other front ends. So far I have only dealt with C/C++, but the FE only changes are usually minimal. 4. Adjust the 10 or so back ends that make MODIFY_EXPR nodes. 5. Merge into mainline. And then... start working on the other tuples. How does this sound to y'all? Aldy
Re: memory benchmark of tuples branch
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.
Re: memory benchmark of tuples branch
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. What I'd like to do next is: 1. Merge mainline into the branch to make sure there are no snafus. 2. Post the patch so folks can look at it while I do 3 & 4: 3. Attack the other front ends. So far I have only dealt with C/C++, but the FE only changes are usually minimal. 4. Adjust the 10 or so back ends that make MODIFY_EXPR nodes. 5. Merge into mainline. And then... start working on the other tuples. How does this sound to y'all? Does the tuples branch include the CALL_EXPR reworking from the LTO branch? Richard.
Re: memory benchmark of tuples branch
> Does the tuples branch include the CALL_EXPR reworking from the LTO branch? No.
Re: memory benchmark of tuples branch
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-3385 x713
Re: memory benchmark of tuples branch
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 about LTO. We seem to have lots of destabilizing stuff in various branches. It may be better to move chunks of long-lived branches as we go along. Particularly things that we feel won't change much over the lifetime of the branch. So, if the CALL_EXPR rework in LTO is "done", we should think about moving it in. But other folks may want to play it more conservatively, so I would rather have consensus here.
