Caroline Tice wrote:
There might be some validity in the idea of modifying this optimization,
in the future, to consider
the size of a basic block in addition to it's "hot-ness", when deciding
which partition to put it into.
I expect this would not be that difficult to implement, and would
proba
I apologize for not responding to these messages sooner; I was out of
town for a few days and only
just read them.
In the first place, I am a little confused about exactly what Joern is
objecting to. If I am reading your
emails correctly, you seem to feel that the hot/cold partitioning
optimiz
On Mon, 2005-02-28 at 00:05, Zdenek Dvorak wrote:
> at the beginning of the stage 1, there always is lot of major changes
> queued up. It never lead to unmanageable amount of "breakage and
> disruption".
Then you clearly haven't tried to maintain a port other than x86-* or
*-linux.
The fact is
> It's in now, BTW. Nothing broke. :-) (As I notified when I submitted the
> patch as an FYI prior to stage 1 opening, this was checked with a native
> bootstrap *and* a cross build.)
The GNAT tools don't build automatically for me anymore, I need to explicitly
'make -C gcc gnattools'.
[EMAIL
Gabriel Dos Reis wrote:
And, yes, I appreciate your work a lot. That does not rule out
occasional disagreements.
I agree.
And, I think Nathanael and I have resolved the situation very
satisfactorily, so, as far as I'm concerned, everything worked as well
as could be hoped.
--
Mark Mitchell
Cod
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Nathanael Nerode wrote:
| >>> Nathanael Nerode wrote:
| > It's in now, BTW. Nothing broke. :-)
|
| We need to talk about that.
|
| Independently of whether or not I made the right decision, your
| decision to check in the patch undermined the process
On Tuesday 01 March 2005 00:49, Mark Mitchell wrote:
> Nathanael Nerode wrote:
> >>>Nathanael Nerode wrote:
> >
> > It's in now, BTW. Nothing broke. :-)
>
> We need to talk about that.
>
> Independently of whether or not I made the right decision, your decision
> to check in the patch undermined
Steven Bosscher wrote:
It's not about how long the branch may live, but the most time it
may have to be maintained before being merged.
We're splitting semantic hairs now, but you need to maintain the branch
during its lifetime, not just the 4 months prior to its merge. Anyway,
this is about all
Andrew Pinski wrote:
But it is documented on our own web site:
http://gcc.gnu.org/develop.html
Yes, I know. I still disagree with it. But don't care enough to keep
arguing about it.
Diego.
Nathanael Nerode wrote:
Nathanael Nerode wrote:
It's in now, BTW. Nothing broke. :-)
We need to talk about that.
Independently of whether or not I made the right decision, your decision
to check in the patch undermined the process. Rather than convincing me
I was in error, or developing a
On Feb 28, 2005, at 6:40 PM, Diego Novillo wrote:
Nathanael Nerode wrote:
"Although maintaining a development branch, including merging new
changes from
the mainline, is somewhat burdensome, the absolute worst case is that
such a
branch will have to be maintained for four months."
This is wrong.
Just to be clear, I do not want to criticize Mark or the Project system in
general. I quite *like* the project sequencing idea. I submitted the
libada-gnattools-branch project as two phases, and I think any major changes
from the second phase are perfectly suited to wait for stage 2. Furthermore
On Tuesday 01 March 2005 00:40, Diego Novillo wrote:
> Nathanael Nerode wrote:
> > "Although maintaining a development branch, including merging new changes
> > from the mainline, is somewhat burdensome, the absolute worst case is
> > that such a branch will have to be maintained for four months."
Nathanael Nerode wrote:
"Although maintaining a development branch, including merging new changes from
the mainline, is somewhat burdensome, the absolute worst case is that such a
branch will have to be maintained for four months."
This is wrong. There is no limit on how long a development branch
>>Nathanael Nerode wrote:
It's in now, BTW. Nothing broke. :-) (As I notified when I submitted the
patch as an FYI prior to stage 1 opening, this was checked with a native
bootstrap *and* a cross build.)
>>The libada-gnattools-branch suffers severely from having to be maintained
>>in parallel
On Mon, 2005-02-28 at 13:25 +0100, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
>
> >People do break Ada bootstrap because they don't configure and test Ada,
> >they don't configure Ada because they complained about Ada build
> >machinery being non standard, delaying Ada build mac
Dale Johannesen wrote:
No, you should not turn on partitioning in situations where code
size is important to you.
You are missing the point. In my example, with perfect profiling
data, you still end up with
more code in the hot section,
Yes.
i.e. more pages are actually swapped in.
Unles
On Feb 28, 2005, at 10:19 AM, Joern RENNECKE wrote:
Dale Johannesen wrote:
Certainly. In general it will make the total size bigger, as does
inlining. If you have good
information about what's hot and cold, it should reduce the number of
pages that actually
get swapped in. The information h
Dale Johannesen wrote:
Certainly. In general it will make the total size bigger, as does
inlining. If you have good
information about what's hot and cold, it should reduce the number of
pages that actually
get swapped in. The information has to be good, though, as a branch from
hot<->cold
On Mon, 2005-02-28 at 10:01 -0800, Dale Johannesen wrote:
> On Feb 28, 2005, at 4:43 AM, Joern RENNECKE wrote:
>
> > Dale Johannesen wrote:
> >
> >>Well, no, what is supposed to happen (I haven't tried it for a
> >> while, so I don't promise
> >> this still works) is code like this:
> >>
> >>
On Feb 28, 2005, at 4:43 AM, Joern RENNECKE wrote:
Dale Johannesen wrote:
Well, no, what is supposed to happen (I haven't tried it for a
while, so I don't promise
this still works) is code like this:
.hotsection:
loop:
conditional branch (i?==1000) to L2
L1:
/* do stuff */
end loop:
/* sti
On Mon, Feb 28, 2005 at 12:43:35PM +, Joern RENNECKE wrote:
> Well, even then, using of the cold section can increase the hot section
> size, depending on target, and for some
> targets the maximum supported distance of the cold section.
>
> For SH, using the cold section, you get (for non-PI
Dale Johannesen wrote:
Well, no, what is supposed to happen (I haven't tried it for a while,
so I don't promise
this still works) is code like this:
.hotsection:
loop:
conditional branch (i?==1000) to L2
L1:
/* do stuff */
end loop:
/* still in hot section */
L2: jmp L3
.coldsection:
L3
In article <[EMAIL PROTECTED]> you write:
>People do break Ada bootstrap because they don't configure and test Ada,
>they don't configure Ada because they complained about Ada build
>machinery being non standard, delaying Ada build machinery changes will
>only make things worse for Ada bootstrap s
On Sun, 2005-02-27 at 14:57 -0800, Mark Mitchell wrote:
> Nathanael Nerode wrote:
> > Although you have listed it as "stage 2", I wish to commit the finished
> > portion as soon as possible during stage 1. I have maintainership authority
> > to do so. This will not interfere in any way with *any*
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
Nathanael said it did not interfere with any of the other _projects_,
not that it would be disjoint from all Stage 1 _patc
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
Nathanael said it did not interfere with any of the other _projects_,
not that it would be disjoint from all Stage 1 _patc
On Feb 27, 2005, at 3:59 PM, Daniel Berlin wrote:
In stark contrast, i believe it is a very good idea for us to be "over
organized" about this. As for judging importance, the release manager
has always judged what is important for a given release, based on
general goals.
I agree. IMO taking one mo
> s/could/absolutely will/. It's a remarkably strong incentive not to
> submit project proposals for 4.2.
Sadly, that's true, if people want to game the system.
Whether or not people do it, the *incentive* still exists and I worry a bit
about creating an incentive to "game the syst
Zdenek Dvorak wrote:
I think it's a little early to start the post-mortem. Perhaps in Stage
3, we could have a better discussion about how well this worked out.
Or, perhaps it will become obvious before then, one way or the other.
agreed. Anyway, thank you for all the work you spend on trying
Daniel Jacobowitz wrote:
The Stage 1 schedule looks full to me, and I'd like to see those patches
go in soon so that we can start shaking out the inevitable problems.
I'm much less worried about the long-term impact of Nathanael's patch;
if it breaks something, it will get fixed, and then that w
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> >On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
>
> >Nathanael said it did not interfere with any of the other _projects_,
> >not that it would be disjoint from all Stage 1 _patches_.
>
> F
Hello,
> >at the beginning of the stage 1, there always is lot of major changes
> >queued up. It never lead to unmanageable amount of "breakage and
> >disruption".
>
> Other people have a different perception than you do.
>
> >As for constructive suggestions -- why not just forget on whole plan
at the beginning of the stage 1, there always is lot of major changes
queued up. It never lead to unmanageable amount of "breakage and
disruption".
Other people have a different perception than you do.
As for constructive suggestions -- why not just forget on whole plan
and let the things work out
Hello,
> (This time around, the there seemed to be consensus that all proposals
> be made public upon submission. Since that seems to be the consensus,
> I'll implement that in the next release cycle.)
yes, this would definitely make sense.
Zdenek
Hello,
> > Zdenek Dvorak writes:
>
> Zdenek> I must admit I have very bad feeling about the whole "4.1 Projects"
> Zdenek> stuff. IMHO this over-organizes things. If people in general
> disagree
> Zdenek> with the Nathan's changes, or if there are any reasons to think that
> Zdenek> they a
On Mon, 2005-02-28 at 00:38 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > >Although you have listed it as "stage 2", I wish to commit the finished
> > >portion as soon as possible during stage 1. I have maintainership
> > >authority
> > >to do so. This will not interfere in any way with *any* of t
Zdenek Dvorak wrote:
Hello,
But I don't think having just a single person
decide which patches may go in and which must wait, or even just judging
their importance, is a good idea.
People weren't happy with the ad-hoc nature of the process before, and I
got a lot of mail about the mainline being
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
Nathanael said it did not interfere with any of the other _projects_,
not that it would be disjoint from all Stage 1 _patches_.
Fair point.
I would certainly prefer that you hold off until Stage 2, as indicated
> Zdenek Dvorak writes:
Zdenek> I must admit I have very bad feeling about the whole "4.1 Projects"
Zdenek> stuff. IMHO this over-organizes things. If people in general disagree
Zdenek> with the Nathan's changes, or if there are any reasons to think that
Zdenek> they are not tested enough or
Hello,
> >Although you have listed it as "stage 2", I wish to commit the finished
> >portion as soon as possible during stage 1. I have maintainership
> >authority
> >to do so. This will not interfere in any way with *any* of the projects
> >approved for stage 1, since it is in a disjoint secti
On Feb 27, 2005, at 6:17 PM, Daniel Jacobowitz wrote:
I think that you need to be a little more specific when asking a
maintainer to hold off on committing a patch that he has authority to
commit, desire to commit, and has been maintaining separately - out of
deference to the 4.0 schedule - for man
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
> Nathanael Nerode wrote:
> >The libada-gnattools-branch suffers severely from having to be maintained
> >in parallel with mainline (since it's a rearrangment of existing code).
> >Another two months of waiting will necessitate many hou
Nathanael Nerode wrote:
The libada-gnattools-branch suffers severely from having to be maintained
in parallel with mainline (since it's a rearrangment of existing code).
Another two months of waiting will necessitate many hours of totally
unneccessary work on my part.
The same is true for everyone
Nathan Sidwell wrote:
Mark Mitchell wrote:
Nathan Sidwell wrote:
You've not included the completion of gcc_assertification, did you miss
that email, or did you not think it necessary to add it as a specific
project, or ... ?
The former; I thought we'd corresponded about that previously? It
seeme
Mark Mitchell wrote:
Nathan Sidwell wrote:
You've not included the completion of gcc_assertification, did you miss
that email, or did you not think it necessary to add it as a specific
project, or ... ?
The former; I thought we'd corresponded about that previously? It
seemed like something that
The libada-gnattools-branch suffers severely from having to be maintained
in parallel with mainline (since it's a rearrangment of existing code).
Another two months of waiting will necessitate many hours of totally
unneccessary work on my part.
The longer the existing portion remains on a branch,
Nathan Sidwell wrote:
Mark Mitchell wrote:
I have posted the GCC 4.1 project submissions I received here:
http://gcc.gnu.org/wiki/GCC%204.1%20Projects
You've not included the completion of gcc_assertification, did you miss
that email, or did you not think it necessary to add it as a specific
pro
Mark Mitchell wrote:
I have posted the GCC 4.1 project submissions I received here:
http://gcc.gnu.org/wiki/GCC%204.1%20Projects
You've not included the completion of gcc_assertification, did you miss
that email, or did you not think it necessary to add it as a specific
project, or ... ?
nathan
-
On Feb 25, 2005, at 9:47 AM, Joern RENNECKE wrote:
consider:
for (;;i++ )
{
if (i == 1000)
i = 0;
/* do stuff... */
}
The "i = 0;" statement is in its own cold block.
On a number of targets, a conditional jump can't reach the cold
section, so you'd have to replace a condjump around a s
In http://gcc.gnu.org/wiki/Hot%20and%20Cold%20Partitioning, you wrote:
> Modifying the hot/cold partitioning optimization to make sure ALL the
> hot blocks come before ALL the cold blocks in the RTL representation.
> This in turn will allow for the elimination of the UNLIKELY notes in
> each cold b
On Feb 25, 2005 10:50 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I have posted the GCC 4.1 project submissions I received here:
>
>http://gcc.gnu.org/wiki/GCC%204.1%20Projects
Nice!
Gr.
Steven
I have posted the GCC 4.1 project submissions I received here:
http://gcc.gnu.org/wiki/GCC%204.1%20Projects
I have divided the projects into several categories:
[1.1] Stage 1.1: Now through March 15th.
[1.2] Stage 1.2: March 15 through April 1st.
[1.3] Stage 1.3: April 1st through April 25th.
[2]
53 matches
Mail list logo
