Re: Question about "instruction merge" pass when optimizing for size

[sa...@hederstierna.com]

> 
> From: Jeff Law 
> More important is to determine *why* we're getting these patterns.  In
> the IRA/LRA world, they should be a lot less common.

Yes I agree this phenomena seems more common after introducing LRA.

Though I was thinking that such a pass still maybe can be relevant.

Thinking hypothetically of an architecture, lets call it cortex-X,
assume this specific target type have an op-code for ADD with 5-operands.

Optimal code for

a = a + b + c + d

would be

addx Ra,Ra,Rb,Rc,Rd

where in the optimization process do we introduce the merging into this target 
type specific instruction.
Can the more generic IRA/LRA handle this?
And maybe patterns can appear across different BB, or somewhere that the normal 
optimizers have hard to find, or figure out?

Sorry if I'm ignorant, I don't know the internals of the different optimizers, 
but I'm trying to learn and understand how to come forward on this issue we 
have with code size currently.
(I tried to but some bugs on it also Bug 61578 and Bug 67213.)

Thanks and Kind Regards, Fredrik

Re: Using the asm suffix

[Andreas Schwab]

David Wohlferd  writes:

> "gcc does not support using this feature with a non-static local variable
> since typically such variables do not have assembler names."

The technical term is "linkage", btw.  An identifier with no linkage has
no visible name in the assembler output.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Possible issue with using LAST_INSN_CODE

[Claudiu Zissulescu]

Hi,

The LAST_INSN_CODE is used to mark the last instruction code valid for a 
particular architecture (e.g., For ARM the value of LAST_INSN_CODE is 3799). 
Also this code (i.e., 3799) is used by a predicated instruction (e.g., for ARM 
this code is used by predicated version of arm_usatsihi => {*p arm_usatsihi}). 

However, the LAST_INSN_CODE macro is used by lra, recog and tree-vect-stmts to 
dimension various arrays which may lead to various errors. 

For example, when calling preprocess_insn_constraints (recog.c:2444), the 
compilation may go berserk when evaluating  "if 
(this_target_recog->x_op_alt[icode])" line when icode is  exactly the 
LAST_INSN_CODE as  "this_target_recog->x_op_alt" is dimensioned up to 
LAST_INSN_CODE (recog.h:397).

A possible solution is having the LAST_INSN_CODE value to be exactly the value 
returned by get_num_isns_codes() (gencodes.c:89). Alternatively is to use 
LAST_INSN_CODE+1 when defining an array.

Please can someone confirm my observation. And what will be the best solution 
for this.

Thanks,
Claudiu

Re: Question about "instruction merge" pass when optimizing for size

[Jeff Law]

On 08/20/2015 01:07 AM, sa...@hederstierna.com wrote:




From: Jeff Law 
More important is to determine *why* we're getting these patterns.  In
the IRA/LRA world, they should be a lot less common.


Yes I agree this phenomena seems more common after introducing LRA.

Though I was thinking that such a pass still maybe can be relevant.

Thinking hypothetically of an architecture, lets call it cortex-X,
assume this specific target type have an op-code for ADD with 5-operands.

Optimal code for

a = a + b + c + d

would be

addx Ra,Ra,Rb,Rc,Rd

where in the optimization process do we introduce the merging into this target 
type specific instruction.
Can the more generic IRA/LRA handle this?
Lots of passes could be involved.  It's better to work with a real 
example on a real target for this kind of discussion.


Assuming sensible three address code comes out of the gimple with 
non-overlapping lifetimes, then I'd expect this to be primarily a 
combiner issue.




And maybe patterns can appear across different BB, or somewhere that the normal 
optimizers have hard to find, or figure out?

Sorry if I'm ignorant, I don't know the internals of the different optimizers, 
but I'm trying to learn and understand how to come forward on this issue we 
have with code size currently.
(I tried to but some bugs on it also Bug 61578 and Bug 67213.)
Unfortunately, 61578 has multiple testcases.  Each should be its own bug 
that can be addressed and tracked individually.


Peeking at the last testcase in c#19 is interesting.  Presumably the 
typecasting is necessary to avoid doing multiple comparisons and the 
assumption is that the casts will be NOPs at the RTL level.


That assumption seems to be fine through IRA.  The allocation seems 
sane, except there's a reload needed for thumb1_addsi3_addgeu to ensure 
operand 1 and operand 0 match due to the matching constraint.


That points to two issues.

1. Is IRA correctly tracking the need for those two operands to be the 
same and accouting for that in its cost model.


2. In the case where IRA still generates code that needs a reload, why 
was the old reload code able to eliminate the copy, the LRA can't.



67213 is probably a costing issue somewhere.  Since Richi is already 
involved, I'll let the two of you dig into the details.


jeff

Re: Possible issue with using LAST_INSN_CODE

[Jeff Law]

On 08/20/2015 02:54 AM, Claudiu Zissulescu wrote:

Hi,

The LAST_INSN_CODE is used to mark the last instruction code valid
for a particular architecture (e.g., For ARM the value of
LAST_INSN_CODE is 3799). Also this code (i.e., 3799) is used by a
predicated instruction (e.g., for ARM this code is used by predicated
version of arm_usatsihi => {*p arm_usatsihi}).

However, the LAST_INSN_CODE macro is used by lra, recog and
tree-vect-stmts to dimension various arrays which may lead to various
errors.

For example, when calling preprocess_insn_constraints (recog.c:2444),
the compilation may go berserk when evaluating  "if
(this_target_recog->x_op_alt[icode])" line when icode is  exactly the
LAST_INSN_CODE as  "this_target_recog->x_op_alt" is dimensioned up to
LAST_INSN_CODE (recog.h:397).

A possible solution is having the LAST_INSN_CODE value to be exactly
the value returned by get_num_isns_codes() (gencodes.c:89).
Alternatively is to use LAST_INSN_CODE+1 when defining an array.

Please can someone confirm my observation. And what will be the best
solution for this.

It seems to me like something has been broken then.

LAST_INSN_CODE is supposed to be higher than any insn defined by the 
backend.



Jeff

Re: Possible issue with using LAST_INSN_CODE

[Claudiu Zissulescu]

Hi Jeff,

In the gencodes.c:89, it explicitly  decrements by one the return
value of get_num_insn_codes(). While for the get_num_insn_codes is
stated this:

/* Return the number of possible INSN_CODEs.  Only meaningful once the
   whole file has been processed.  */

I can provide an example for the ARC port where it crashes due to
LAST_INSN_CODE issue. Probably it can be reproduced with other more
popular port like ARM.

//Claudiu


On Thu, Aug 20, 2015 at 6:54 PM, Jeff Law  wrote:
> On 08/20/2015 02:54 AM, Claudiu Zissulescu wrote:
>>
>> Hi,
>>
>> The LAST_INSN_CODE is used to mark the last instruction code valid
>> for a particular architecture (e.g., For ARM the value of
>> LAST_INSN_CODE is 3799). Also this code (i.e., 3799) is used by a
>> predicated instruction (e.g., for ARM this code is used by predicated
>> version of arm_usatsihi => {*p arm_usatsihi}).
>>
>> However, the LAST_INSN_CODE macro is used by lra, recog and
>> tree-vect-stmts to dimension various arrays which may lead to various
>> errors.
>>
>> For example, when calling preprocess_insn_constraints (recog.c:2444),
>> the compilation may go berserk when evaluating  "if
>> (this_target_recog->x_op_alt[icode])" line when icode is  exactly the
>> LAST_INSN_CODE as  "this_target_recog->x_op_alt" is dimensioned up to
>> LAST_INSN_CODE (recog.h:397).
>>
>> A possible solution is having the LAST_INSN_CODE value to be exactly
>> the value returned by get_num_isns_codes() (gencodes.c:89).
>> Alternatively is to use LAST_INSN_CODE+1 when defining an array.
>>
>> Please can someone confirm my observation. And what will be the best
>> solution for this.
>
> It seems to me like something has been broken then.
>
> LAST_INSN_CODE is supposed to be higher than any insn defined by the
> backend.
>
>
> Jeff

Re: Possible issue with using LAST_INSN_CODE

[Jeff Law]

On 08/20/2015 11:28 AM, Claudiu Zissulescu wrote:

Hi Jeff,

In the gencodes.c:89, it explicitly  decrements by one the return
value of get_num_insn_codes(). While for the get_num_insn_codes is
stated this:

/* Return the number of possible INSN_CODEs.  Only meaningful once the
whole file has been processed.  */

I can provide an example for the ARC port where it crashes due to
LAST_INSN_CODE issue. Probably it can be reproduced with other more
popular port like ARM.

Passing along a test, even for the ARC is useful.

This is something Richard recently changed, it's probably just an 
oversight on his part.   I believe he's in the UK and may be offline for 
the day.


jeff

Moving to git

[Jason Merrill]

I hear that at Cauldron people were generally supportive of switching 
over to git as the primary GCC repository, and talked about me being 
involved in that transition.  Does anyone have more information about 
this discussion?


Our current workflow translates over to a git master pretty easily: 
basically, in the current git-svn workflow, replace git svn rebase and 
git svn dcommit with git pull --rebase and git push.


It should be pretty straightforward to use the existing git mirror as 
the master repository; the main adjustment I'd want to make is rewriting 
the various subdirectory branches to be properly represented in git. 
This is straightforward, but we'll want to stop SVN commits to 
subdirectory branches shortly before the changeover.


It would be good to have a more explicit policy on branch/tag creation, 
rebasing, and deletion in the git world where branches are lighter 
weight and so more transient.


Jason

Re: Moving to git

[Jeff Law]

On 08/20/2015 11:57 AM, Jason Merrill wrote:

I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition.  Does anyone have more information about
this discussion?

Our current workflow translates over to a git master pretty easily:
basically, in the current git-svn workflow, replace git svn rebase and
git svn dcommit with git pull --rebase and git push.

Right.



It should be pretty straightforward to use the existing git mirror as
the master repository; the main adjustment I'd want to make is rewriting
the various subdirectory branches to be properly represented in git.
This is straightforward, but we'll want to stop SVN commits to
subdirectory branches shortly before the changeover.

Seems reasonable.

I think we also need to convert our SVN hooks into git hooks, but 
presumably that'll be easy.


I suspect Jakub will strongly want to see some kind commit hook to 
associate something similar to an SVN id to each git commit to support 
his workflow where the SVN ids are  associated with the compiler 
binaries he keeps around for very fast bisection.  I think when we 
talked about it last year, he just needs an increasing # for each 
commit, presumably starting with whatever the last SVN ID is when we 
make the change.





It would be good to have a more explicit policy on branch/tag creation,
rebasing, and deletion in the git world where branches are lighter
weight and so more transient.
Presumably for branch/tag creation the primary concern is the namespace? 
 I think if we define a namespace folks can safely use without getting 
in the way of the release managers we get most of what we need.


ISTM that within that namespace, folks ought to have the freedom to use 
whatever works for them.  If folks want to create a transient branch, 
push-rebase-push on that branch, then later remove it, I tend to think, 
why not let them.


Do we want a namespace for branches which are perhaps not as transient 
in nature, ie longer term projects, projects on-ice or works-in-progress 
that we don't want to lose?


As far as the trunk and release branches, are there any best practices 
out there that we can draw from?  Obviously doing things like 
push-rebase-push is bad.  Presumably there's others.


jeff

Re: Possible issue with using LAST_INSN_CODE

[Richard Sandiford]

Jeff Law  writes:
> On 08/20/2015 11:28 AM, Claudiu Zissulescu wrote:
>> Hi Jeff,
>>
>> In the gencodes.c:89, it explicitly  decrements by one the return
>> value of get_num_insn_codes(). While for the get_num_insn_codes is
>> stated this:
>>
>> /* Return the number of possible INSN_CODEs.  Only meaningful once the
>> whole file has been processed.  */
>>
>> I can provide an example for the ARC port where it crashes due to
>> LAST_INSN_CODE issue. Probably it can be reproduced with other more
>> popular port like ARM.
> Passing along a test, even for the ARC is useful.
>
> This is something Richard recently changed, it's probably just an 
> oversight on his part.

Yeah :-(  That's a mightly confusing name.  I'm going to try changing
it to NUM_INSN_CODES and make it a const unsigned int (rather than
keeping it as part of the enum).

Thanks,
Richard

Re: Moving to git

[David Malcolm]

On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
> I hear that at Cauldron people were generally supportive of switching 
> over to git as the primary GCC repository, and talked about me being 
> involved in that transition.  Does anyone have more information about 
> this discussion?
> 
> Our current workflow translates over to a git master pretty easily: 
> basically, in the current git-svn workflow, replace git svn rebase and 
> git svn dcommit with git pull --rebase and git push.
> 
> It should be pretty straightforward to use the existing git mirror as 
> the master repository; the main adjustment I'd want to make is rewriting 
> the various subdirectory branches to be properly represented in git. 
> This is straightforward, but we'll want to stop SVN commits to 
> subdirectory branches shortly before the changeover.
> 
> It would be good to have a more explicit policy on branch/tag creation, 
> rebasing, and deletion in the git world where branches are lighter 
> weight and so more transient.

If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?

Currently:
https://www.gnu.org/software/gcc/svnwrite.html#checkin says:

"The log message for that checkin should be the complete ChangeLog entry
for the change."

and the subsection "Commit the changes to the central repository" below
https://www.gnu.org/software/gcc/svnwrite.html#example
has an example showing this.


In the git world, the first line of the commit message has special
meaning, being treated as the "title" of the commit.
Quoting the git docs [1]:
  "Though not required, it’s a good idea to begin the commit message
with a single short (less than 50 character) line summarizing the
change, followed by a blank line and then a more thorough description.
The text up to the first blank line in a commit message is treated as
the commit title, and that title is used throughout Git. For example,
git-format-patch[1] turns a commit into email, and it uses the title on
the Subject line and the rest of the commit in the body."


For gcc, I suggest that the first line of the commit message should be a
representative title, typically the "Subject" line of the relevant
gcc-patches thread (without any "[PATCH]" prefix), and this should be
followed by the ChangeLog entry as before as the "more thorough
description" that the git docs speak of.

Looking at the commit history, many contributors appear to be already
applying this policy when committing to svn (I'm one of them); it makes
the history much easier to read from git (otherwise the title is
typically something like "gcc/" or just a datestamp and email, which
isn't as helpful).  Try running "git shortlog" on a git mirror of the
current repo to see what I mean.

For example:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227033
which when viewed from git has the title:
"[ARM] Hide existing float16 intrinsics unless we have a scalar __fp16
type".

I'm merely proposing doing this going forward, *not* to attempt any kind
of retroactive history-editing (ugh).

I can write it up for the website if people agree it's a good policy.

Hope this is constructive.
Dave

[1] http://git-scm.com/docs/git-commit (see "DISCUSSION")

Re: Moving to git

[Jason Merrill]

On 08/20/2015 02:23 PM, Jeff Law wrote:

I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are  associated with the compiler
binaries he keeps around for very fast bisection.  I think when we
talked about it last year, he just needs an increasing # for each
commit, presumably starting with whatever the last SVN ID is when we
make the change.


Jakub: How about using git bisect instead, and identify the compiler 
binaries with the git commit sha1?



It would be good to have a more explicit policy on branch/tag creation,
rebasing, and deletion in the git world where branches are lighter
weight and so more transient.

Presumably for branch/tag creation the primary concern is the namespace?
  I think if we define a namespace folks can safely use without getting
in the way of the release managers we get most of what we need.

ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them.  If folks want to create a transient branch,
push-rebase-push on that branch, then later remove it, I tend to think,
why not let them.


Makes sense.


Do we want a namespace for branches which are perhaps not as transient
in nature, ie longer term projects, projects on-ice or works-in-progress
that we don't want to lose?


Currently such branches are at the top level, but I think it would make 
sense to categorize them more, including moving many existing branches 
into subdirectories indicating that they were either merged or 
abandoned.  We might want to delete some old branches entirely.



As far as the trunk and release branches, are there any best practices
out there that we can draw from?  Obviously doing things like
push-rebase-push is bad.  Presumably there's others.


Absolutely, a non-fast-forward push is anathema for anything other 
people might be working on.  The git repository already prohibits this; 
people that want to push-rebase-push their own branches need to delete 
the branch before pushing again.


There are many opinions about best practices, but I don't think any of 
them are enough better than what we already do to justify a change.


'git help workflow' describes how development of git itself works: they 
have "maint", "master" and "next" branches that would roughly correspond 
to our latest release branch, trunk, and next-stage-1-trunk.  Having a 
"next" branch could be useful, but I think we deliberately don't have 
one currently in order to focus people on release preparation during 
stage 3 rather than it always being stage 1 somewhere.


One interesting thing that they do is to keep earlier branches merged 
into later branches, so 4.9 into 5, 5 into trunk, trunk into next.  This 
is an interesting discipline, but I'm not sure it is of much practical 
value.


Jason

Re: Moving to git

[Jason Merrill]

On 08/20/2015 03:31 PM, David Malcolm wrote:

On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:

I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition.  Does anyone have more information about
this discussion?

Our current workflow translates over to a git master pretty easily:
basically, in the current git-svn workflow, replace git svn rebase and
git svn dcommit with git pull --rebase and git push.

It should be pretty straightforward to use the existing git mirror as
the master repository; the main adjustment I'd want to make is rewriting
the various subdirectory branches to be properly represented in git.
This is straightforward, but we'll want to stop SVN commits to
subdirectory branches shortly before the changeover.

It would be good to have a more explicit policy on branch/tag creation,
rebasing, and deletion in the git world where branches are lighter
weight and so more transient.


If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?

Currently:
https://www.gnu.org/software/gcc/svnwrite.html#checkin says:

"The log message for that checkin should be the complete ChangeLog entry
for the change."

and the subsection "Commit the changes to the central repository" below
https://www.gnu.org/software/gcc/svnwrite.html#example
has an example showing this.


In the git world, the first line of the commit message has special
meaning, being treated as the "title" of the commit.
Quoting the git docs [1]:
   "Though not required, it’s a good idea to begin the commit message
with a single short (less than 50 character) line summarizing the
change, followed by a blank line and then a more thorough description.
The text up to the first blank line in a commit message is treated as
the commit title, and that title is used throughout Git. For example,
git-format-patch[1] turns a commit into email, and it uses the title on
the Subject line and the rest of the commit in the body."


For gcc, I suggest that the first line of the commit message should be a
representative title, typically the "Subject" line of the relevant
gcc-patches thread (without any "[PATCH]" prefix), and this should be
followed by the ChangeLog entry as before as the "more thorough
description" that the git docs speak of.


Sounds good to me.


Looking at the commit history, many contributors appear to be already
applying this policy when committing to svn (I'm one of them); it makes
the history much easier to read from git (otherwise the title is
typically something like "gcc/" or just a datestamp and email, which
isn't as helpful).  Try running "git shortlog" on a git mirror of the
current repo to see what I mean.

For example:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227033
which when viewed from git has the title:
"[ARM] Hide existing float16 intrinsics unless we have a scalar __fp16
type".

I'm merely proposing doing this going forward, *not* to attempt any kind
of retroactive history-editing (ugh).

I can write it up for the website if people agree it's a good policy.

Hope this is constructive.
Dave

[1] http://git-scm.com/docs/git-commit (see "DISCUSSION")

Re: Moving to git

[Paul_Koning]

> On Aug 20, 2015, at 4:09 PM, Jason Merrill  wrote:
> 
> On 08/20/2015 02:23 PM, Jeff Law wrote:
>> ...As far as the trunk and release branches, are there any best practices
>> out there that we can draw from?  Obviously doing things like
>> push-rebase-push is bad.  Presumably there's others.
> 
> Absolutely, a non-fast-forward push is anathema for anything other people 
> might be working on.  The git repository already prohibits this; people that 
> want to push-rebase-push their own branches need to delete the branch before 
> pushing again.
> 
> There are many opinions about best practices, but I don't think any of them 
> are enough better than what we already do to justify a change.

Let's make sure the procedures that people are supposed to follow are clearly 
documented.  I recently went looking for the equivalent in the binutils/gdb 
project and it doesn't seem to be written down there, though if you ask enough 
questions on the mailing list you do get some answers.

paul

Re: Moving to git

[Jason Merrill]

On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote:

Let's make sure the procedures that people are supposed to follow are clearly 
documented.  I recently went looking for the equivalent in the binutils/gdb 
project and it doesn't seem to be written down there, though if you ask enough 
questions on the mailing list you do get some answers.


Do you have pointers to relevant email threads?

Jason

Re: Moving to git

[Jonathan Wakely]

On 20 August 2015 at 19:23, Jeff Law wrote:
> On 08/20/2015 11:57 AM, Jason Merrill wrote:
>>
>> I hear that at Cauldron people were generally supportive of switching
>> over to git as the primary GCC repository, and talked about me being
>> involved in that transition.  Does anyone have more information about
>> this discussion?
>>
>> Our current workflow translates over to a git master pretty easily:
>> basically, in the current git-svn workflow, replace git svn rebase and
>> git svn dcommit with git pull --rebase and git push.
>
> Right.
>
>>
>> It should be pretty straightforward to use the existing git mirror as
>> the master repository; the main adjustment I'd want to make is rewriting
>> the various subdirectory branches to be properly represented in git.
>> This is straightforward, but we'll want to stop SVN commits to
>> subdirectory branches shortly before the changeover.
>
> Seems reasonable.
>
> I think we also need to convert our SVN hooks into git hooks, but presumably
> that'll be easy.
>
> I suspect Jakub will strongly want to see some kind commit hook to associate
> something similar to an SVN id to each git commit to support his workflow
> where the SVN ids are  associated with the compiler binaries he keeps around
> for very fast bisection.  I think when we talked about it last year, he just
> needs an increasing # for each commit, presumably starting with whatever the
> last SVN ID is when we make the change.

IIUC you can get a per-branch rev number with:

git rev-list --count --first-parent 

e.g.

$ git rev-list --count --first-parent trunk
140323

I believe this says there are 140323 commits between the beginning of
time and trunk.

That's per-branch though, not a global revision number across all
branches. (Maybe that's more useful anyway?)

The number of commits on trunk since the gcc-5-branch point is:

$ git rev-list --count --first-parent trunk ^gcc-5-branch
2877

I don't know if this is useful.

FWIW I like David's suggestion of useful commit summaries in the first line.

Re: Moving to git

[Florian Weimer]

* Jeff Law:

> I suspect Jakub will strongly want to see some kind commit hook to
> associate something similar to an SVN id to each git commit to support
> his workflow where the SVN ids are  associated with the compiler
> binaries he keeps around for very fast bisection.

As long as we do not rebase,

  git log --pretty=format: | wc -l

is actually pretty close to a revision number, and it's reasonably
quick to compute.  The number will be meaningful only within a single
branch.  It's also prudent to capture the head commit hash when the
number is generated because subsequent merges may make it complicated
to map the number back to the original branch head when the number was
computed.

> ISTM that within that namespace, folks ought to have the freedom to
> use whatever works for them.  If folks want to create a transient
> branch, push-rebase-push on that branch, then later remove it, I tend
> to think, why not let them.

They could use a completely separate repository, too, and still have
working merges from mainline.

Re: Moving to git

[Joseph Myers]

On Thu, 20 Aug 2015, Jason Merrill wrote:

> It should be pretty straightforward to use the existing git mirror as the
> master repository; the main adjustment I'd want to make is rewriting the

I think using the existing git mirror for this is a bad idea.  To quote 
: "Use git-svn for live gatewaying if you 
must, remaining aware that it is not the safest tool in the world. But for 
a full conversion use a dedicated importing tool.".

I think a proper conversion to git as the master repository should 
reconvert all the history with author ids properly mapped and subdirectory 
branches properly handled as such throughout the conversion.  (I don't 
think other oddities are worth cleaning up unless it's easy to e.g. clean 
up cvs2svn oddities in the conversion process, or unless someone is 
particularly keen on cleaning them up, and don't think any attempt should 
be made to rewrite existing commit messages.  And if using reposurgeon, I 
think its special handling of svn:ignore and .cvsignore should be 
disabled, keeping .cvsignore in older history and our existing .gitignore 
in newer history as we already have a well-maintained .gitignore file - 
that way maybe git tags can keep contents identical to the corresponding 
SVN tags.)

The two histories could then be combined in a single git repository by 
renaming all the existing refs in the git repository not to conflict with 
those from the proper conversion, and if desired adding a merge commit on 
master to converge the two histories.  The two histories would share blob 
objects and hopefully tree objects as well (but of course not commit 
objects), so this shouldn't increase the space taken up by too much.

> It would be good to have a more explicit policy on branch/tag creation,
> rebasing, and deletion in the git world where branches are lighter weight and
> so more transient.

In general, we should have updated versions of all documentation relating 
to the use of the repository (that's mainly svn.html and svnwrite.html), 
and of scripts in maintainer-scripts, before doing the final move.

* Policy on commit messages, as already discussed (though I'd say that 
generally the substantive part of the gcc-patches message about the patch 
is useful to include as well as the ChangeLog entry).  (This policy would 
only be for master and official release branches; for other branches it 
would be up to the people using them.)

* As standard for shared repositories, hooks should disallow any 
non-fast-forward pushes (this means you can't rebase and then push to the 
same branch without deleting it in between).

* Decide whether to allow branch deletion.  If so, I'd say it should only 
be for branches inside personal / company namespaces.  (If a branch is 
simply obsolete, don't remove it.)

* Do we want the hooks disallowing trailing whitespace on new / modified 
lines?  (I'd be inclined to say yes.)

* Do we want hooks to send diffs to gcc-cvs as well as commit messages?  
(binutils-gdb uses hooks that do that with size limits on the amount of 
diffs sent.)

* In the common case where you try to push a commit and find that someone 
else committed to master so the push fails, you should git pull --rebase 
rather than plain git pull before pushing again, so the history on master 
remains linear in such cases; merge commits on master, if any, should be 
limited to merges of more substantial development branches.

* Specifically do not associate any changes in workflow with the move to 
git.  Exactly the same release branching and development arrangements 
would be used, ChangeLog files would continue to be updated manually.  If 
someone wishes to (say) set up arrangements for generating ChangeLogs at 
release time rather than putting entries in them at commit time, that 
should be something completely separate after the move to git.

* Make sure whatever process updates the github mirror is kept going after 
the conversion (actually it looks like it broke two weeks ago...).

* I encourage using the wwwdocs repository as a test-bed for the 
conversion.  Its history is so much simpler that once you have the author 
map worked out, almost any tool would probably produce a good conversion, 
and such a conversion could be used to test hooks before converting the 
main repository.  (I expect in any case that a few trial conversions of 
the main repository would be needed for people to review before we're 
ready for the final conversion.  wwwdocs would be a reasonable test-bed 
for hooks, but not for conversion complications.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Moving to git

[Paul_Koning]

> On Aug 20, 2015, at 4:24 PM, Jason Merrill  wrote:
> 
> On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote:
>> Let's make sure the procedures that people are supposed to follow are 
>> clearly documented.  I recently went looking for the equivalent in the 
>> binutils/gdb project and it doesn't seem to be written down there, though if 
>> you ask enough questions on the mailing list you do get some answers.
> 
> Do you have pointers to relevant email threads?

It was in a private email exchange.  Here's what I wrote and the reply I 
received:

>> I used to know the GDB workflow back in the CVS days, but GIT is of course 
>> very different.  I’m not particularly fluent with GIT.  Some of the projects 
>> in our company that I’m starting to get involved with use it.  I’ve seen 
>> their procedures documents and they mention that GIT supports an amazing 
>> variety of work flows with very different visible outcomes.  For example, it 
>> seems to make a lot of difference whether you allow branching that’s natural 
>> to GIT development to remain visible in the history, or rebase (I think 
>> that’s the right term) everything before it’s pushed to create the 
>> appearance of a single stream of history.
>> 
>> I gather GDB is one of those single linear history projects, but I haven’t 
>> yet found any documents that describe the GDB development procedures as far 
>> as GIT is concerned.  Can you point to some?
> 
> Yeah, gdb's git workflow is similar to the CVS days.  We rebase patches on 
> top of master
> to maintain a linear history.  That is, only fast-forward merges are accepted.
> Don't worry, if you get this wrong and try to push a non-linear merge, the 
> server
> will reject it with an error.  At which point you just pull/fetch upstream 
> again,
> rebase your patch, and push again.
> 
> I'm afraid I'm not aware of any GDB-specific docs for that.  Though, glibc
> follows a similar model and they do have a guide.  See:
> 
>  https://sourceware.org/glibc/wiki/Committer%20checklist
> 
> The git-specifics are the same for gdb. 

paul

Re: Adding static-PIE support to binutils

[Rich Felker]

On Wed, Aug 19, 2015 at 03:01:20PM +, Joseph Myers wrote:
> If a new option is added, of course it needs documenting in the ld manual 
> (ld.texinfo).

I can do that and resubmit the patch, but is there consensus that
adding a new option is appropriate? Like I said before I mildly lean
that way because it's more flexible.

Rich

Re: Adding static-PIE support to binutils

[Joseph Myers]

On Thu, 20 Aug 2015, Rich Felker wrote:

> On Wed, Aug 19, 2015 at 03:01:20PM +, Joseph Myers wrote:
> > If a new option is added, of course it needs documenting in the ld manual 
> > (ld.texinfo).
> 
> I can do that and resubmit the patch, but is there consensus that
> adding a new option is appropriate? Like I said before I mildly lean
> that way because it's more flexible.

I have no views on whether a new option is appropriate (I agree with the 
high-level principle of supporting static PIEs).

-- 
Joseph S. Myers
jos...@codesourcery.com

Should we remove remnants of UWIN support in gcc/config.* files?

[FX]

UWIN support was apparently removed from GCC in 2008. Yet some traces can still 
be found in gcc/config.* files.
Attached patch would remove them. OK to commit?

FX


PS: gcc/config.host and gcc/config.build include some other such targets… 
without checking them all, I think the following could be removed:

powerpc-*-beos
i370-*-opened* | i370-*-mvs*
i386-*-vsta
i[34567]86-*-udk*
i[34567]86-*-sysv4*
i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4*
i[34567]86-*-sco3.2v5*

Is there a good reason for not removing those targets? If not, I’ll try to 
track them down, check that they are indeed unsupported, and propose a patch 
removing them.





uwin.ChangeLog
Description: Binary data


uwin.diff
Description: Binary data

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joseph Myers]

On Thu, 20 Aug 2015, FX wrote:

> PS: gcc/config.host and gcc/config.build include some other such 
> targets… without checking them all, I think the following could be 
> removed:
> 
> powerpc-*-beos
> i370-*-opened* | i370-*-mvs*
> i386-*-vsta
> i[34567]86-*-udk*
> i[34567]86-*-sysv4*
> i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4*
> i[34567]86-*-sco3.2v5*
> 
> Is there a good reason for not removing those targets? If not, I’ll try 
> to track them down, check that they are indeed unsupported, and propose 
> a patch removing them.

Well, they aren't *targets*, but *host* and *build* systems.  However, I 
don't think any of them are actually significantly relevant to GCC now as 
host or build systems (and nor do I think we need case statements for 
unsupported host or build systems - just let people try to build and 
possibly have the build fail, a fix for such a failure would better use 
autoconf than special-casing a triplet anyway).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[FX]

> Well, they aren't *targets*, but *host* and *build* systems.

Yes, but do we maintain a list of support host or build systems, that would be 
different from our list of supported targets?
(That’s a question out of curiosity. I do agree with the rest of your message: 
in practice, they are not supported.)

FX

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joseph Myers]

On Thu, 20 Aug 2015, FX wrote:

> > Well, they aren't *targets*, but *host* and *build* systems.
> 
> Yes, but do we maintain a list of support host or build systems, that 
> would be different from our list of supported targets?

I don't think there's such a list.  For any such system that's not a 
supported target to work in practice, it would need a reasonably modern 
C++ compiler, which probably rules out a lot of systems that have been 
obsoleted as targets.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Should we remove remnants of UWIN support in gcc/config.* files?

[Joel Sherrill]

On August 20, 2015 5:22:47 PM EDT, Joseph Myers  wrote:
>On Thu, 20 Aug 2015, FX wrote:
>
>> > Well, they aren't *targets*, but *host* and *build* systems.
>> 
>> Yes, but do we maintain a list of support host or build systems, that
>
>> would be different from our list of supported targets?
>
>I don't think there's such a list.  For any such system that's not a 
>supported target to work in practice, it would need a reasonably modern
>
>C++ compiler, which probably rules out a lot of systems that have been 
>obsoleted as targets.

Wouldn't a list be able to be compiled from major branch release announcements? 
There should be a deprecated and removed note in two release branch 
descriptions. Even if we screwed up and forgot to list it on both, if it likely 
to be in one of them.

--joel

Re: Moving to git

[Segher Boessenkool]

On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
> If we're going to migrate to git (I hope so), can we also please
> *slightly* revise the policy on commit messages, to add meaningful
> titles to commits?
> 
> Currently:
> https://www.gnu.org/software/gcc/svnwrite.html#checkin says:
> 
> "The log message for that checkin should be the complete ChangeLog entry
> for the change."
> 
> and the subsection "Commit the changes to the central repository" below
> https://www.gnu.org/software/gcc/svnwrite.html#example
> has an example showing this.
> 
> 
> In the git world, the first line of the commit message has special
> meaning, being treated as the "title" of the commit.

It would be nice if we could use a real commit message, not just a short
title line; for example, people who prepare their patches in git already
have that, and use it with format-patch as you say.  And many bonus points
if we don't have to repeat the changelog in the commit message (it's in
the commit already, the bugzilla hook could just pull it from out there).

Or we could have another discussion about if we want to have changelogs
at all...


Segher

Re: Moving to git

[Jason Merrill]

On 08/20/2015 04:33 PM, Joseph Myers wrote:

On Thu, 20 Aug 2015, Jason Merrill wrote:


It should be pretty straightforward to use the existing git mirror as the
master repository; the main adjustment I'd want to make is rewriting the


I think using the existing git mirror for this is a bad idea.  To quote
: "Use git-svn for live gatewaying if you
must, remaining aware that it is not the safest tool in the world. But for
a full conversion use a dedicated importing tool.".



I think a proper conversion to git as the master repository should
reconvert all the history with author ids properly mapped and subdirectory
branches properly handled as such throughout the conversion.  (I don't
think other oddities are worth cleaning up unless it's easy to e.g. clean
up cvs2svn oddities in the conversion process, or unless someone is
particularly keen on cleaning them up, and don't think any attempt should
be made to rewrite existing commit messages.  And if using reposurgeon, I
think its special handling of svn:ignore and .cvsignore should be
disabled, keeping .cvsignore in older history and our existing .gitignore
in newer history as we already have a well-maintained .gitignore file -
that way maybe git tags can keep contents identical to the corresponding
SVN tags.)

The two histories could then be combined in a single git repository by
renaming all the existing refs in the git repository not to conflict with
those from the proper conversion, and if desired adding a merge commit on
master to converge the two histories.  The two histories would share blob
objects and hopefully tree objects as well (but of course not commit
objects), so this shouldn't increase the space taken up by too much.


Thanks for the pointers, that all makes sense.


It would be good to have a more explicit policy on branch/tag creation,
rebasing, and deletion in the git world where branches are lighter weight and
so more transient.


In general, we should have updated versions of all documentation relating
to the use of the repository (that's mainly svn.html and svnwrite.html),
and of scripts in maintainer-scripts, before doing the final move.


Yes.


* Policy on commit messages, as already discussed (though I'd say that
generally the substantive part of the gcc-patches message about the patch
is useful to include as well as the ChangeLog entry).  (This policy would
only be for master and official release branches; for other branches it
would be up to the people using them.)


Agreed.


* As standard for shared repositories, hooks should disallow any
non-fast-forward pushes (this means you can't rebase and then push to the
same branch without deleting it in between).


Yes, this is already the case for the git-svn mirror.


* Decide whether to allow branch deletion.  If so, I'd say it should only
be for branches inside personal / company namespaces.  (If a branch is
simply obsolete, don't remove it.)


This is also currently the policy of the git-svn mirror.


* Do we want the hooks disallowing trailing whitespace on new / modified
lines?  (I'd be inclined to say yes.)


I'm not sure how many people would care about this without git nagging 
them, but sure.



* Do we want hooks to send diffs to gcc-cvs as well as commit messages?
(binutils-gdb uses hooks that do that with size limits on the amount of
diffs sent.)


I don't read gcc-cvs, so I don't have an opinion about this.  I wouldn't 
expect it to be useful, but presumably binutils-gdb have a reason for 
doing it.



* In the common case where you try to push a commit and find that someone
else committed to master so the push fails, you should git pull --rebase
rather than plain git pull before pushing again, so the history on master
remains linear in such cases; merge commits on master, if any, should be
limited to merges of more substantial development branches.


Absolutely.


* Specifically do not associate any changes in workflow with the move to
git.  Exactly the same release branching and development arrangements
would be used, ChangeLog files would continue to be updated manually.  If
someone wishes to (say) set up arrangements for generating ChangeLogs at
release time rather than putting entries in them at commit time, that
should be something completely separate after the move to git.


Agreed.


* Make sure whatever process updates the github mirror is kept going after
the conversion (actually it looks like it broke two weeks ago...).


I have no idea how this mirror is updated.  Its github page is 
remarkably uninformative.



* I encourage using the wwwdocs repository as a test-bed for the
conversion.  Its history is so much simpler that once you have the author
map worked out, almost any tool would probably produce a good conversion,
and such a conversion could be used to test hooks before converting the
main repository.  (I expect in any case that a few trial conversions of
the main repository would be needed for people to review before

Re: Moving to git

[Jason Merrill]

On 08/20/2015 06:32 PM, Segher Boessenkool wrote:

On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:

If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?

Currently:
https://www.gnu.org/software/gcc/svnwrite.html#checkin says:

"The log message for that checkin should be the complete ChangeLog entry
for the change."

and the subsection "Commit the changes to the central repository" below
https://www.gnu.org/software/gcc/svnwrite.html#example
has an example showing this.


In the git world, the first line of the commit message has special
meaning, being treated as the "title" of the commit.


It would be nice if we could use a real commit message, not just a short
title line; for example, people who prepare their patches in git already
have that, and use it with format-patch as you say.


I think that's what David was suggesting; a short title line, followed 
by a blank line, followed by a more substantive commit message.


This change doesn't need to be tied to the git transition; it could 
happen either before or after.



And many bonus points
if we don't have to repeat the changelog in the commit message (it's in
the commit already, the bugzilla hook could just pull it from out there).

Or we could have another discussion about if we want to have changelogs
at all...


That's a good question, but I think it's definitely independent.

Jason

Re: Moving to git

[Jonathan Wakely]

On 20 August 2015 at 23:32, Jason Merrill wrote:
> On 08/20/2015 04:33 PM, Joseph Myers wrote:
>> * Make sure whatever process updates the github mirror is kept going after
>> the conversion (actually it looks like it broke two weeks ago...).
>
>
> I have no idea how this mirror is updated.  Its github page is remarkably
> uninformative.


AFAIK it's nothing official, just set up by someone out in the
interwebs, and it is always broken. It has all the commits, but
doesn't move the trunk and master refs correctly.

I don't think it should have any bearing on transitioning the official
repo to git.

Re: Controlling instruction alternative selection

[Paul Shortis]

Thanks Jim,

It took me a while to get back to this problem but as you 
suggested, exposing only the three address instructions prior to 
reload... in conjunction with implementing


TARGET_CLASS_LIKELY_SPILLED_P

has produced good results. After taking these measures I didn't 
have to disparage any alternatives in the patterns.


Paul.

On 04/08/15 06:00, Jim Wilson wrote:

On 07/30/2015 09:54 PM, Paul Shortis wrote:

Resulting in ...
error: unable to find a register to spill in class ‘GP_REGS’

enabling lra and inspecting the rtl dump indicates that both
alternatives (R and r) seem to be equally appealing to the allocater so
it chooses 'R' and fails.

The problem isn't in lra, it is in reload.  You want lra to use the
three address instruction, but you then want reload to use the two
address alternative.


Using constraint disparaging (?R) eradicates the errors, but of course
that causes the 'R' three address alternative to never be used.

You want to disparage the three address alternative in reload, but not
in lra.  There is a special code for that, you can use ^ instead of ? to
make that happen.  That may or may not help though.

There is also a hook TARGET_CLASS_LIKELY_SPILLED_P which might help.
You should try defining this to return true for the 'R' class if it
doesn't already.

Jim

[RFC]: Vectorization cost benefit changes.

[Ajit Kumar Agarwal]

All:

I have done the vectorization cost changes as given below. I have considered 
only the cost associated with the inner instead of outside.
The consideration of inside scalar and vector cost is done as the inner cost 
are the most cost effective than the outside cost.

 min_profitable_iters = ((scalar_single_iter_cost
- vec_inside_cost) *vf);

The Scalar_single_iter_cost consider the hardcoded value 50 which is used for 
most of the targets and the scalar cost is multiplied
With 50. This scalar cost is subtracted with vector cost and as the scalar cost 
is increased the chances of vectorization is more with same
Vectorization factor  and more loops will be vectorized.

I have not changed the iteration count which is hardcoded with 50 and I will do 
the changes to replace the 50 with the static
Estimates of iteration count if you agree upon the below changes. 

I have ran the SPEC cpu 2000 benchmarks with the below changes for i386 targets 
and the significant gains are achieved with respect
To INT and FP benchmarks.

Here is the data.

Ratio of vectorization cost changes(FP benchmarks) vs Ratio of without 
vectorization cost changes( FP benchmarks)  = 4640.102 vs 4583.379.
Ratio of vectorization cost changes (INT benchmarks ) vs Ratio of without 
vectorization cost changes( INT benchmarks0 = 3812.883 vs 3778.558

Please give your feedback on the below changes for vectorization cost benefit.

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 422b883..35d538f 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2987,11 +2987,8 @@ vect_estimate_min_profitable_iters (loop_vec_info 
loop_vinfo,
 min_profitable_iters = 1;
   else
 {
-  min_profitable_iters = ((vec_outside_cost - scalar_outside_cost) * vf
- - vec_inside_cost * peel_iters_prologue
-  - vec_inside_cost * peel_iters_epilogue)
- / ((scalar_single_iter_cost * vf)
-- vec_inside_cost);
+  min_profitable_iters = ((scalar_single_iter_cost
+- vec_inside_cost) *vf);

   if ((scalar_single_iter_cost * vf * min_profitable_iters)
   <= (((int) vec_inside_cost * min_profitable_iters)

Thanks & Regards
Ajit


vect.diff
Description: vect.diff