Re: GCC GSoC 2020: Call for mentors and project ideas

[Nicholas Krause]

On 1/16/20 8:33 AM, Nathan Sidwell wrote:

On 1/15/20 5:45 PM, Martin Jambor wrote:


Therefore, first and foremost, I would like to ask all (moderately)
seasoned GCC contributors to consider mentoring a student this year and
ideally also come up with a project that they would like to lead.  I'm
collecting proposal on our wiki page
https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
top list there.  Or, if you are unsure, post your offer and project idea
as a reply here to the mailing list.


I have an idea for a GNU-Make project.

* Separate Make's job-control from the dependency walking.  Right now, 
theses are somewhat tangled up, due to history.  It would be nice to 
separate these into distinct components.  One wrinkle may be that 
single-threaded invocation might need to preserve the 
(implementation-defined) order of dependent rule execution, as 
makefiles that do not completely specify dependencies might be relying 
on that.


I ran into this problem with my hack to add a module-server into make, 
and hacked around it in an ugly fashion.


(I've not run this by the GNU-Make maintainers)

nathan


Martin,
I've been looking into something similar to the scheduler for GCC 
parallelizing. Its a lot harder
than it seems due to IPA passes and other things like IPO. Not sure how 
Richard was planning to
handle that and unfortunately I've been busy and unable to write up my 
ideas for scaling GCC.


Since it may be awhile before it reaches the wiki page here is a link to 
a rough draft of my

ideas:https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit?usp=sharing

I will be exploring the tooling issues when I'm time as that was my next 
step.


Sorry if there are grammar issues as its a rough draft,
Nick

GCC Multi-Threading Ideas

[Nicholas Krause]

Greetings All,

Unfortunately due to me being rather busy with school and other things I 
will not be able to post my article to the wiki for awhile. However 
there is a  rough draft here:

https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit
that may change a little for people to read in the meantime.

Please forgive me if there are grammar errors due to it being a draft. 
However, the discussion needs to continue in terms of long term and GSoC 
planning in terms of this project. In addition, Richard mentioned 
something similar to async workqueues but the biggest issue isn't the 
garbage collector. The bigger issue is how do we work around IPO passes 
and order them in order to avoid missed optimizations. Further more I've 
been thinking about it on and off, but it seems that there will be 
issues/compromise  no matter what. Therefore due to this, the community 
at large will need to decide what policies we will have about IPO in a 
multi-threaded gcc including IPA passes.


If there are any questions about the draft let me know or ideas about 
the IPO ordering issues including IPA passes you can contact me here.


Sorry for not keeping you up to date as much after Cauldron,
Nick

Re: GCC Multi-Threading Ideas

[Nicholas Krause]

On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote:

On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote:

Greetings All,

Unfortunately due to me being rather busy with school and other things I
will not be able to post my article to the wiki for awhile. However
there is a  rough draft here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMj
Oxk/edit that may change a little for people to read in the meantime.


This comment might not be suited for your project, but now that I think about
it: If we want to improve gcc toolchain buildspeed with better multithreading.
I think the most sensible would be fixing up gold multithreading and enabling
it by default. We already get most of the benefits of multicore architectures
by running multiple compile jobs in parallel (yes, I know you are focusing on
cases where that for some reason doesn't work, but it is still the case in
most situations). The main bottleneck is linking. The code is even already
there in gold and have been for years, it just haven't been deemed ready for
being enabled by default.

Is anyone even working on that?

Best regards
Allan

Allan,
You would need both depending on the project, some are more compiler
bottle necked and others linker. I mentioned that issue at Cauldron as
the other side would be the linker.

Nick

Re: GCC Multi-Threading Ideas

[Nicholas Krause]

On 1/23/20 12:19 PM, Nicholas Krause wrote:



On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote:

On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote:

Greetings All,

Unfortunately due to me being rather busy with school and other 
things I

will not be able to post my article to the wiki for awhile. However
there is a  rough draft here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMj 


Oxk/edit that may change a little for people to read in the meantime.

This comment might not be suited for your project, but now that I 
think about
it: If we want to improve gcc toolchain buildspeed with better 
multithreading.
I think the most sensible would be fixing up gold multithreading and 
enabling
it by default. We already get most of the benefits of multicore 
architectures
by running multiple compile jobs in parallel (yes, I know you are 
focusing on
cases where that for some reason doesn't work, but it is still the 
case in
most situations). The main bottleneck is linking. The code is even 
already
there in gold and have been for years, it just haven't been deemed 
ready for

being enabled by default.

Is anyone even working on that?

Best regards
Allan

Allan,
You would need both depending on the project, some are more compiler
bottle necked and others linker. I mentioned that issue at Cauldron as
the other side would be the linker.

Nick
Sorry for the second message Allan but make -j does not scale well 
beyond 4 or

8 threads and that's considering a 4 core or 8 machine. The problem has to
do with large build machines with CPUs with more cores than this or as 
is becoming

more common on mainstream systems.

Nick

Re: GCC Multi-Threading Ideas

[Nicholas Krause]

On 1/23/20 12:19 PM, Nicholas Krause wrote:



On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote:

On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote:

Greetings All,

Unfortunately due to me being rather busy with school and other 
things I

will not be able to post my article to the wiki for awhile. However
there is a  rough draft here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMj 


Oxk/edit that may change a little for people to read in the meantime.

This comment might not be suited for your project, but now that I 
think about
it: If we want to improve gcc toolchain buildspeed with better 
multithreading.
I think the most sensible would be fixing up gold multithreading and 
enabling
it by default. We already get most of the benefits of multicore 
architectures
by running multiple compile jobs in parallel (yes, I know you are 
focusing on
cases where that for some reason doesn't work, but it is still the 
case in
most situations). The main bottleneck is linking. The code is even 
already
there in gold and have been for years, it just haven't been deemed 
ready for

being enabled by default.

Is anyone even working on that?

Best regards
Allan

Allan,
You would need both depending on the project, some are more compiler
bottle necked and others linker. I mentioned that issue at Cauldron as
the other side would be the linker.

Nick
Sorry for the second message Allan but make -j does not scale well 
beyond 4 or

8 threads and that's considering a 4 core or 8 machine. The problem has to
do with large build machines with CPUs with more cores than this or as 
is becoming

more common on mainstream systems.

It's for future proofing and making it better for production level build 
machines,

Nick

Re: GCC Multi-Threading Ideas

[Nicholas Krause]

On 1/24/20 3:18 AM, Allan Sandfeld Jensen wrote:

On Freitag, 24. Januar 2020 04:38:48 CET Nicholas Krause wrote:

On 1/23/20 12:19 PM, Nicholas Krause wrote:

On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote:

On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote:

Greetings All,

Unfortunately due to me being rather busy with school and other
things I
will not be able to post my article to the wiki for awhile. However
there is a  rough draft here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9
gUMj

Oxk/edit that may change a little for people to read in the meantime.

This comment might not be suited for your project, but now that I
think about
it: If we want to improve gcc toolchain buildspeed with better
multithreading.
I think the most sensible would be fixing up gold multithreading and
enabling
it by default. We already get most of the benefits of multicore
architectures
by running multiple compile jobs in parallel (yes, I know you are
focusing on
cases where that for some reason doesn't work, but it is still the
case in
most situations). The main bottleneck is linking. The code is even
already
there in gold and have been for years, it just haven't been deemed
ready for
being enabled by default.

Is anyone even working on that?

Best regards
Allan

Allan,
You would need both depending on the project, some are more compiler
bottle necked and others linker. I mentioned that issue at Cauldron as
the other side would be the linker.

Nick

Sorry for the second message Allan but make -j does not scale well
beyond 4 or
8 threads and that's considering a 4 core or 8 machine.

It doesn't? I generally build with -j100, but then also use icecream to
distribute builds to multiple machines in the office. That probably also makes
linking times more significant to my case.

'Allan


Allan,

I ran a gcc build on a machine with make -j32 and -j64 that had 64 cores. There 
was literally only
a 4 minute increase in build speed. Good question through.

Nick

Re: GCC Multi-Threading Ideas

[Nicholas Krause]

On 1/24/20 1:28 PM, Allan Sandfeld Jensen wrote:

On Freitag, 24. Januar 2020 17:29:06 CET Nicholas Krause wrote:

On 1/24/20 3:18 AM, Allan Sandfeld Jensen wrote:

On Freitag, 24. Januar 2020 04:38:48 CET Nicholas Krause wrote:

On 1/23/20 12:19 PM, Nicholas Krause wrote:

On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote:

On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote:

Greetings All,

Unfortunately due to me being rather busy with school and other
things I
will not be able to post my article to the wiki for awhile. However
there is a  rough draft here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIp
C9
gUMj

Oxk/edit that may change a little for people to read in the meantime.

This comment might not be suited for your project, but now that I
think about
it: If we want to improve gcc toolchain buildspeed with better
multithreading.
I think the most sensible would be fixing up gold multithreading and
enabling
it by default. We already get most of the benefits of multicore
architectures
by running multiple compile jobs in parallel (yes, I know you are
focusing on
cases where that for some reason doesn't work, but it is still the
case in
most situations). The main bottleneck is linking. The code is even
already
there in gold and have been for years, it just haven't been deemed
ready for
being enabled by default.

Is anyone even working on that?

Best regards
Allan

Allan,
You would need both depending on the project, some are more compiler
bottle necked and others linker. I mentioned that issue at Cauldron as
the other side would be the linker.

Nick

Sorry for the second message Allan but make -j does not scale well
beyond 4 or
8 threads and that's considering a 4 core or 8 machine.

It doesn't? I generally build with -j100, but then also use icecream to
distribute builds to multiple machines in the office. That probably also
makes linking times more significant to my case.

'Allan

Allan,

I ran a gcc build on a machine with make -j32 and -j64 that had 64 cores.
There was literally only a 4 minute increase in build speed. Good question
through.


Right. I guess it entirely depends on what you are building. If you are
building gcc, it is probably bound by multiple configure runs, and separate
iterations. What I usually build is Qt and Chromium, where thousands of files
can be compiled from a single configure run (more than 2 in the case of
Chromium), plus those configure runs are much faster. For Chromium there is
almost a linear speed up with the number of parallel jobs you run up to around
100. With -j100 I can build Chromium in 10 minutes, with 2 minutes being
linking time (5 minutes linking if using bfd linker). With -j8 it takes 2
hours.

But I guess that means multithreading the compiler can make sense to your
case, even if it doesn't to mine.

Regards
'Allan



Allan,
The question I would have is make -j on one machine as that's my
point. You can distribute it out with icecream or other thinks but
again that doesn't always help. In the paper in does mention
interaction with make and build systems to make it scale better
if possible. Not sure how QT or Chromium would be directly
affected. However its a considered use case where make scales
fine but may do better with coupling into the internal compiler
multi-threading. Again even 10 minutes should be make better
if make interacted with gcc multi-threading well.

Nick

SSA Question related to Dominator Trees

[Nicholas Krause]

Greetings,

Sorry if this question has been asked before but do we extend out the 
core tree type for SSA or
is there a actual dominator tree type. It seems to be we just extend or 
override the core tree

type parameters but was unable to verify it by looking in the manual.

Thanks,

Nick

Re: SSA Question related to Dominator Trees

[Nicholas Krause]

On 1/27/20 10:46 AM, Jeff Law wrote:

On Mon, 2020-01-27 at 10:18 -0500, Nicholas Krause wrote:

Greetings,

Sorry if this question has been asked before but do we extend out the
core tree type for SSA or
is there a actual dominator tree type. It seems to be we just extend or
override the core tree
type parameters but was unable to verify it by looking in the manual.

There is no type or class for the dominator tree.  Having one would be
useful.


jeff

Jeff,
Thought so and the manual isn't very clear on all of the state used by 
it and where,
so implementing a class may be tricky. After looking in ssa.h seems that 
there are

four main header files for definitions:
gimple-ssa.h
tree-ssanames.h
tree-phinodes.h
ssa-iterators.h

I've not sure if there are other files lying around related to dom tree 
walking but

I'm ccing Richard as he would know better than me where the other parts are.

It also makes sense to contain it if we want to make the domtrees and 
SSA passes

multi threaded aware,
Nick

SSA Iterators

[Nicholas Krause]

Greetings,

I was looking into starting to cleaning up the SSA trees for various 
reasons and iterators
seem to be the easiest to do. I searched the list to see if someone 
mentioned it before

and I ran across this:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02031.html

If your trying to get a second ++ working then why not override it 
prefix as your
just doing it for postfix and those can be separate. Its not ideal to 
have two
different versions for prefix and postfix in terms of overloading but it 
may be

the simplest solution here.

Nick

Re: SSA Iterators

[Nicholas Krause]

On 1/30/20 11:25 AM, Richard Biener wrote:

On January 30, 2020 5:05:09 PM GMT+01:00, Martin Sebor  wrote:

On 1/30/20 2:59 AM, Jonathan Wakely wrote:

On Thu, 30 Jan 2020, 05:44 Nicholas Krause wrote:

Greetings,

I was looking into starting to cleaning up the SSA trees for various
reasons and iterators
seem to be the easiest to do. I searched the list to see if someone
mentioned it before
and I ran across this:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02031.html

If your trying to get a second ++ working then why not override it
prefix as your
just doing it for postfix and those can be separate.

No no no.

No.


Its not ideal to
have two
different versions for prefix and postfix in terms of overloading

but it

may be
the simplest solution here.

No, making pre-increment and post-incrememt so different things (i.e.
iterate over different ranges) is a horrible idea. That's the kind of
thing that gives operator overloading a bad name. Overloaded

operators

should do the thing you expect them to. They should not be used to
hide a non-obvious action behind an apparently simple syntax.


I would suggest avoiding "smart" iterators that contain all the state
and know their own end point. Instead create a type that holds all

the

state and has begin/end member functions which return an iterator

that

refers to the state. And have the iterator  dereference to some other
object that has the state for the second level of iteration, with its
own begin/end members returning the second iterator type. That would
end up looking like:

imm_use_stmt_range r (SSAVAR);
for (imm_use_stmt_iter it = r.begin (); it != r.end (); ++it)
  for (imm_use_on_stmt_iter it2 = it->begin (); it2 != it->end ();

++it2)

;

At some point when we move to C++11 or later that could become:

imm_use_stmt_range r (SSAVAR);
for (auto& stmt : r)
  for (auto& on_stmt : *stmt)
;

That's a good goal to aim for with all GCC "iterators," including
those behind the legacy FOREACH_XXX macros.  I posted a patch for
one of these in 2018 but it was too late in the development cycle
and I didn't get back to in in 2019:
   https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01549.html

If you're working on a general cleanup in this are please consider
these as well.

We should definitely aim for a standard way, adding yet another one doesn't 
help. Which is why I was trying to tackle the more difficult one(s) first. Most 
of the iterators should be trivial to convert to whatever style we settle on.

Richard.

Richard,

I do recall there was some agreement on moving to C++11 last year so for 
each loops
should be fine. I'm only aware of the SSA iterators as I was   just 
researching the SSA
code. Not sure of the others as those were the other ones mentioned in 
the GCC manual

from memory.

In addition the STL mentions const, standard and reverse iterators. I'm 
assuming we

only need standard but perhaps const versions may be useful  as well.

Regards,

Nick



Martin

Re: Git question: Rebasing a user branch

[Nicholas Krause]

On 2/4/20 5:02 PM, Bill Schmidt wrote:
I'm having a little difficulty with my workflow, and I'm hoping 
someone can spot the problem.


I have a user branch set up with the contrib/git-add-user-branch.sh 
script.  Here are the relevant portions of my .git/config:


[remote "users/wschmidt"]
    url = git+ssh://wschm...@gcc.gnu.org/git/gcc.git
    fetch = 
+refs/users/wschmidt/heads/*:refs/remotes/users/wschmidt/*

    fetch = +refs/users/wschmidt/tags/*:refs/tags/users/wschmidt/*
    push = refs/heads/wschmidt/*:refs/users/wschmidt/heads/*
[branch "wschmidt/builtins"]
    remote = users/wschmidt
    merge = refs/users/wschmidt/heads/builtins
Not sure why but this seems fishy to me. Does merge need to be the same 
as push
if your trying to avoid creating a new branch.  So removing the builtins 
and making
it refs/users/wschmidt/heads/* would be my guess. I'm not a git expert 
through.


Nick


I originally created the branch from master.  I then made 15 local 
commits, and pushed these upstream.


I now want to rebase my branch from master, and reflect this state 
upstream.  My recipe is:


git checkout master
git pull
git checkout wschmidt/builtins
git rebase master
git push --dry-run users/wschmidt +wschmidt/builtins

After the rebase step, git status shows:

On branch wschmidt/builtins
Your branch and 'users/wschmidt/builtins' have diverged,
and have 39 and 15 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

Looks fine to me, so lets try the force push:

wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run 
users/wschmidt +wschmidt/builtins

To git+ssh://gcc.gnu.org/git/gcc.git
 * [new branch]  wschmidt/builtins -> wschmidt/builtins

Well, that's odd, why is it trying to create a new branch?

If I inadvisedly attempt to push without --dry-run, I am stopped from 
creating the new branch:


remote: *** Shared development branches should be named devel/*, and 
should be documented in https://gcc.gnu.org/git.html .

remote: error: hook declined to update refs/heads/wschmidt/builtins
To git+ssh://gcc.gnu.org/git/gcc.git
 ! [remote rejected] wschmidt/builtins -> wschmidt/builtins 
(hook declined)
error: failed to push some refs to 
'git+ssh://wschm...@gcc.gnu.org/git/gcc.git'


It seems wrong that it is trying to update refs/head/wschmidt/builtins 
(thus creating a new branch).  It seems like there may be a missing 
"users/" needed someplace.  But I am not at all confident that's 
correct.  I'm a little suspicious of the push spec in my config.


Can someone with strong git-fu give me any suggestions?

Best regards,
Bill

GSoC Questions

[Nicholas Krause]

Greetings Martin,

I won't be applied but it was good to see you at least got some possible 
ideas out of
my research from the make parts. Two questions as related to GSoC, in 
terms of

long term planning for my work:

1. *Implement something similar to Clang's/-ftime-trace/*is in my view 
the most important project
for GCC multi-threading as having a real profiler in gcc proper is the 
biggest bottleneck. Finding
shared state and having heuristics is a real thorn without it. Is the 
goal just to support it as a
feature similar to Clang or is this intended to be a real profiler, as 
it seems so?


2.*Create a general jobserver client/server library *If its planning to 
be a library then your
probably hooking it into the frontends for C/C++.  Not sure who the 
maintainer for that is
but is he aware of the possible changes? It may be good to either have 
him as another
mentor or someone to ask about the frontend parts unless you or Martin 
Liska have

that knowledge.

Regards and good luck with GSoC,

Nick**

Re: GSoC Questions

[Nicholas Krause]

On 2/5/20 10:34 AM, Martin Liška wrote:

On 2/5/20 7:21 AM, Nicholas Krause wrote:

Greetings Martin,

I won't be applied but it was good to see you at least got some 
possible ideas out of
my research from the make parts. Two questions as related to GSoC, in 
terms of

long term planning for my work:


Hello.



1. *Implement something similar to Clang's/-ftime-trace/*is in my 
view the most important project
for GCC multi-threading as having a real profiler in gcc proper is 
the biggest bottleneck.


Here I would definitely recommend perf which can identify bottleneck, 
as well as locking issues

and so on.
Perf is fine but because of the complexity of GCC it does not need great 
data outside
of how much time times take and even them its not great. Basically I've 
only found
out that functions and certain core data structures are used. Its a 
little hard to explain
but its a issue that the GSoC student from last semester was/is running 
into as well.
Basically more fine grained internal data is required then perf seems 
able to give.
One example is figuring out the size of SSA nodes to figure out the best 
ideas in
terms of making the dominantor trees multi-threaded safe/aware. The 
other would
be that it states the garbage collector is using only 5% of the time on 
a machine
with over 100GB of ram. However it does not take into account all of the 
functions

that interact with the garbage collector through GTY() in that percent.



Finding
shared state and having heuristics is a real thorn without it. Is the 
goal just to support it as a
feature similar to Clang or is this intended to be a real profiler, 
as it seems so?


My intention was to do the same what clang does. The format is quite 
generic and can be easily

extended to support more.
That's fine and expected as long as we can extend it out. The bigger 
concern was if we were

unable to.




2.*Create a general jobserver client/server library *If its planning 
to be a library then your
probably hooking it into the frontends for C/C++.  Not sure who the 
maintainer for that is
but is he aware of the possible changes? It may be good to either 
have him as another
mentor or someone to ask about the frontend parts unless you or 
Martin Liska have

that knowledge.


No, first consumer of that should be LTO WPA which runs parallel LTO 
LTRANS during linking.

I'm not targeting any hooking into FEs.
That's fine if you want to do LTO first. Didn't know that was the 
intended first goal.


P.S. Please CC me next time if you speak about me ;)

Sorry about that and will do it the future,
Nick


Thanks,
Martin



Regards and good luck with GSoC,

Nick**

Re: [EXTERNAL] Re: GCC selftest improvements

[Nicholas Krause]

On 2/12/20 8:53 PM, David Malcolm wrote:

On Thu, 2020-02-13 at 00:49 +, Modi Mo wrote:

Hey all,

I'm picking this work up from Andrew. Last time it was decided that
the timing wasn't right to upgrade the minimum version to C++11. Is
the timing better now to get this change through?

I've attached the patch Andrew prepared. Can I get feedback on the
change and some help testing on the broader range of
architectures/platforms?

Thanks,
Modi

Hi Modi

Thanks for the patch.

Some nitpicks:

Timing-wise, the GCC developer community is focusing on gcc 10
bugfixing right now (aka "stage 4" of the release cycle).  So this
patch won't be suitable to commit to master until stage 1 of the
release cycle for gcc 11 (in April, hopefully).

But yes, it's probably a good idea to get feedback on the patch given
the breadth of platforms we support.

The patch will need an update to the docs; search for
"Tools/packages necessary for building GCC" in gcc/doc/install.texi,
which currently has some paragraphs labelled:
   @item ISO C++98 compiler
that will need changing.

I think Richi mentioned that the minimum gcc version should be 4.8.2 as
he recalled issues with .1, so maybe the error message and docs should
reflect that?
   https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html


This may be opening a can of worms that should wait until we're done
with the GCC 10 release, but there's probably an eventual wider
discussion about what parts of C++11 we should use; pragmatically we're
also limited by gengtype, the tool that scrapes the source code looking
for garbage-collector markup, as that imposes a subset of C++ on us.

I'd love to be able to rely on move semantics and thus use e.g.
std::unique_ptr to capture more of our memory-management in the type
system (we currently have a limited C++98-compatible implementation in
the tree in the form of gnu::unique_ptr).

How much of the stdlib do we see ourselves using?  I think we've
avoided std::string and the <<-style stream APIs; is there a case for
using some of the other data structures?

For reference, see
   https://gcc.gnu.org/codingconventions.html#Cxx_Conventions
(looks like that page would need an update also for the version bump;
it's in the website git repo IIRC)

Hope this is constructive.
Dave

Dave,

I recall originally bringing up the move. From memory I recall that 
these were the

features we wanted or the people in the discussion wanted from C++11:
1. Better Rounding and Stricter Integer and other number type rules
2. Template Aliasing
3. Auto and for each style loops
4. Move and R Value Semantics

There was a little discussion about lambas and anonymous functions but I 
don't

recall that being clear in terms of one of the above areas for sure.

Maybe that helps,
Nick

Re: Fwd: [llvm-dev] Open Source Hackathon Mentorship Invitation

[Nicholas Krause]

Not sorry why this was dropped.
Nick

On 2/18/20 4:03 PM, Nicholas Krause wrote:


Greetings All,
This was from the LLVM list but it may interest some people here on 
the GCC side.

I've not part of the university or have any relationship with them.

Maybe some people are interested,

Nick

 Forwarded Message 
Subject:[llvm-dev] Open Source Hackathon Mentorship Invitation
Date:   Tue, 18 Feb 2020 10:42:32 -0800
From:   Misha Patel via llvm-dev 
Reply-To:   Misha Patel 
To: llvm-...@lists.llvm.org



Hello,

My name is Misha Patel and I’m reaching out on behalf of the 
HackIllinois Outreach team. HackIllinois is a 36-hour collegiate Open 
Source hackathon that takes place annually at the University of 
Illinois Urbana-Champaign. This year, it will be from February 
28th-March 1st, 2020. Our mission is to introduce college students to 
Open Source, while giving back to the community. We strive to create a 
collaborative environment in which our attendees can learn from and 
work with developers to make their own contributions. In past years, 
we’ve had developers from prominent projects such as npm, Rust, and 
Apache come to mentor students from our pool of 900+ attendees.


We’d love it if you could pass along this message to the LLVM Compiler 
Infrastructure community or any individuals you believe would be 
interested. We will provide meals throughout the event and can 
reimburse for travel and lodging up to a certain amount depending on 
where in the US people are coming from. More information on mentorship 
can be found at hackillinois.org/mentor 
<http://hackillinois.org/mentor>. You can also visit 
opensource.hackillinois.org <http://opensource.hackillinois.org> to 
see what kinds of projects were represented at our event last year.


We'd be more than happy to discuss this further. Please have any 
interested individuals contact us at opensou...@hackillinois.org 
<mailto:opensou...@hackillinois.org>. Looking forward to hearing back!


Best,
Misha Patel
HackIllinois 2020 Outreach Director
misha.pa...@hackillinois.org <mailto:misha.pa...@hackillinois.org>

Typo in Tree SSA Passes

[Nicholas Krause]

Greetings,
Not sure who to contact but at the manual page:
https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html#Tree-SSA-passes
Enter static single assignment form

This pass rewrites the function such that it is in SSA form. After this 
pass, all|is_gimple_reg|variables will be referenced by|SSA_NAME|, and 
all occurrences of other variables will be annotated 
with|VDEFS|and|VUSES|; PHI nodes will have been inserted as necessary 
for each basic block. This pass is located intree-ssa.cand is described 
by|pass_build_ssa|.


The pass seems to be in tree-into-ssa.c these days.

Someone should update that if possible,

Nick

Make LTO Patch for Job Server Thread Detection Agnostic

[Nicholas Krause]

Greetings Martin,

This patch:
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06

May have a small problem with the lines:
+  const char *makeflags = getenv ("MAKEFLAGS");
+  if (makeflags == NULL)
+return false; I'm not sure if ninja or other build systems use that 
for detection or have it as a variable you can use. This may be an issue 
with ninja, cmake and other build systems that may not have it. Maybe 
I'm wrong but it may be good to check that, Nick

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Nicholas Krause]

On 2/27/20 3:44 AM, Jonathan Wakely wrote:

On Thu, 27 Feb 2020 at 06:50, Nicholas Krause  wrote:

Greetings Martin,

This patch:
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06

May have a small problem with the lines:
+  const char *makeflags = getenv ("MAKEFLAGS");
+  if (makeflags == NULL)
+return false; I'm not sure if ninja or other build systems use that
for detection or have it as a variable you can use. This may be an issue
with ninja, cmake and other build systems that may not have it. Maybe
I'm wrong but it may be good to check that, Nick

The patch is to use Make's jobserver, it's not expected to work with
arbitrary build systems.

Martin, the comment in your patch says "-std=c11" which should be c++11.


Jonathan,

That's a problem then as were assuming a user's build system for this to 
work. I mean
for now its fine but in the future wouldn't it de a good ideal to not 
assume this?


Nick

Re: Help implementing support for vec in gengtype

[Nicholas Krause]

On 2/27/20 12:56 PM, Giuliano Belinassi wrote:

Hi, all.

I am tying to fix an issue with a global variable in the parallel gcc
project. For this, I am trying to move some global variables from
tree-ssa-operands to struct function. One of this variable is a
vec type, and gengtype doesn't look so happy with it.

In this context, I am trying to add support to vec to gengtype.
Therefore, I first fixed a problem where gengtype couldn't find the
tree union by:

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 53317337cf8..6f4c77020ea 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -638,7 +638,10 @@ create_user_defined_type (const char *type_name, struct fil
eloc *pos)
   /* Strip off the first '*' character (and any subsequent text). 
*/
   *(field_name + offset_to_star) = '\0';
  
- arg_type = find_structure (field_name, TYPE_STRUCT);

+ arg_type = resolve_typedef (field_name, pos);
+ if (!arg_type)
+   arg_type = find_structure (field_name, TYPE_STRUCT);
+
   arg_type = create_pointer (arg_type);
 }
   else

After this patch, gengtype seems to correctly detect vec types,
but then I face linking issues. At first, the compiler could not find
gt_ggc_mx (vec *v) and gt_pch_mx (vec *v), therefore I implemented
them both in gcc/vec.h:

diff --git a/gcc/vec.h b/gcc/vec.h
index 091056b37bc..dfa744b684e 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1306,6 +1306,15 @@ vec::quick_grow_cleared (unsigned len)
  vec_default_construct (address () + oldlen, growby);
  }
  
+template

+void
+gt_ggc_mx (vec *v)
+{
+  extern void gt_ggc_mx (T &);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_ggc_mx ((*v)[i]);
+}
+
  /* Garbage collection support for vec.  */
  
  template

@@ -1328,6 +1337,15 @@ gt_ggc_mx (vec *v 
ATTRIBUTE_UNUSED)
  
  /* PCH support for vec.  */
  
+template

+void
+gt_pch_nx (vec *v)
+{
+  extern void gt_pch_nx (T &);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_pch_nx ((*v)[i]);
+}
+
  template
  void
  gt_pch_nx (vec *v)
@@ -1337,6 +1355,14 @@ gt_pch_nx (vec *v)
  gt_pch_nx ((*v)[i]);
  }
  
+template

+void
+gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
+{
+  for (unsigned i = 0; i < v->length (); i++)
+op (&((*v)[i]), cookie);
+}
+
template
  void
  gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
@@ -1354,6 +1380,15 @@ gt_pch_nx (vec *v, gt_pointer_operator 
op, void *cookie)
  gt_pch_nx (&((*v)[i]), op, cookie);
  }
  
+template

+void
+gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
+{
+  extern void gt_pch_nx (T *, gt_pointer_operator, void *);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_pch_nx (&((*v)[i]), op, cookie);
+}
+

After that, I get linking errors because the linker can not find
gt_ggc_mx (tree *&x) nor void gt_pch_nx (tree *&x). The thing
is: it doesn't matter where I implement them, or if I declare
them inline. I always get a linking error one way or another.

Therefore, what should I do to correctly implement the support
for vec types?

Thank you,
Giuliano.


Giuliano,
If your talking about gcc/vec.h there seems to be versions of them 
defined starting
on line 1304 of the mainline tree after grepping the source code. Not 
sure if the

linker is complaining about that as I don't have your errors.

Maybe that helps you out,

Nick

Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

[Nicholas Krause]

Greetings All,

After doing some more research it seems that it may be time to remove 
the garbage collector. I'm
aware of the linkage to precompiled headers but even them I think its 
time due to two reasons:


1. The work related to multithreading gcc is working around the global 
state of the collector which
makes scaling less likely in terms of threads. In addition it is 
causing   unnecessary compilations

in terms of workarounds in this project.

2. Memory usage may be decreased in certain passes due to being able to 
implement memory allocation
at a pass or per pass type level with more knowledge than a generic 
garbage collector. I'm aware this
is done for a lot of passes. However it  could be done for the other 
passes that are linked currently to the

garbage collector.

I'm not sure what memory allocation strategies we want to implement in 
terms of replacing the garbage

collector but I think its time.

On another I'm looking into the issues with PHI nodes and operators as 
to how to lock or decrease global
state there as this seems to be the biggest complication when I've time. 
In addition as Jeff stated we
will also want to encapsulate SSA operands and other SSA related things 
in a series of classes as part of

this.


Regards,
Nick

Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

[Nicholas Krause]

On 2/27/20 3:02 PM, David Malcolm wrote:

On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote:

Greetings All,

After doing some more research it seems that it may be time to
remove
the garbage collector. I'm
aware of the linkage to precompiled headers but even them I think
its
time due to two reasons:

1. The work related to multithreading gcc is working around the
global
state of the collector which
makes scaling less likely in terms of threads. In addition it is
causing   unnecessary compilations
in terms of workarounds in this project.

2. Memory usage may be decreased in certain passes due to being able
to
implement memory allocation
at a pass or per pass type level with more knowledge than a generic
garbage collector. I'm aware this
is done for a lot of passes. However it  could be done for the other
passes that are linked currently to the
garbage collector.

I'm not sure what memory allocation strategies we want to implement
in
terms of replacing the garbage
collector but I think its time.

Nick, you've sent various emails to this list suggesting big changes to
GCC's codebase (updating from C++98 to C++11 is another one that
springs to mind), but I believe you've yet to send the project an
actual patch for anything.

 I did awhile but most of them were bug fixes on bugzilla. Not
sure if any got merged. Most of these days I doing research so
sorry about that. If your not familiar with it my work is here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit 



It's great that you want to help, and that you have ideas about the
high-level architecture of the project, but may I respectfully suggest
you start with something *much* smaller and more concrete?   There are
plenty of bugs in BZ that could use attention.

Of course this was to be long term :). Like the C++11 its more to
get others involved in planning for it. The change patch was
small for C++11. The problem really was testing and figuring out
language support which I helped out with.

Very sorry if your misunderstanding me or my work,
Nick


Hope this is constructive
David


On another I'm looking into the issues with PHI nodes and operators
as
to how to lock or decrease global
state there as this seems to be the biggest complication when I've
time.
In addition as Jeff stated we
will also want to encapsulate SSA operands and other SSA related
things
in a series of classes as part of
this.


Regards,
Nick

MLIR Dialects for Multi-Threading GCC

[Nicholas Krause]

Greetings All,

Seems the LLVM side has made a multi threaded pass manager in MLIR:
https://mlir.llvm.org/docs/WritingAPass/

It also seems to have fixed a lot of the issues around my research in
SSA. There are two ways to look into using MLIR either:

a) Write a dialect of it for GIMPLE
b) Use the ideas but implement them internally in GCC rewriting passes
into the core infrastructure as need be

Not sure if other people think its a good idea or there are license issues,
Nick

SSA Operands Locking

[Nicholas Krause]

Greetings,

After looking through the manual there seem to be a number of for 
iterating marcos related to
PHI or SSA nodes. Since iterating through nodes is shared state I was 
wondering whether we
should lock internal to the marco itself around the iteration or around 
each caller of one of these
marcos and just update the manual to warn about that in terms of 
implementing Multi-Threading.
It doesn't really matter in terms of technical functionality but should 
we assume that developers
will remember to lock a mutex around these iteration marcos for SSA or 
PHI nodes.



Not sure about the status of C++11 but when it gets merged we can just 
lock this using std::mutex,


Nick

Re: [PATCH] Weird Linker Error

[Nicholas Krause]

Please forget  this email seems it was a dumb typo.

Nick

On 2/28/20 5:44 PM, Nicholas Krause wrote:

From: Nicholas Krause 

Greetings,

Sorry if this is a dumb question but I'm not sure if this is a linker
error due to not linking pthreads or something else going on. I'm assuming
its something to do with enabling pthreads but what's weird is it
does not warn the types are not defined but gives me errors like:

/home/xerofoify/GCC/../gcc/gcc/tree.h:3763: multiple definition of 
`phi_stmt_iterator_mutex'
cfgexpand.o:/home/xerofoify/GCC/../gcc/gcc/dumpfile.h:215: first defined here
omp-grid.o:(.bss+0x0): multiple definition of `imm_iteration_mutex'
cfgexpand.o:/home/xerofoify/GCC/../gcc/gcc/hwint.h:214: first defined here
omp-grid.o: In function `bool need_finalization_p, tree_node*> >::hash_entry>()':

I've checked those lines and none of them seem to be dealing with
SSA iterators. Thanks in advance for the help.

Signed-off-by: Nicholas Krause 
---
  gcc/ssa-iterators.h | 28 
  1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/gcc/ssa-iterators.h b/gcc/ssa-iterators.h
index 98724da..65d8e3b 100644
--- a/gcc/ssa-iterators.h
+++ b/gcc/ssa-iterators.h
@@ -16,6 +16,7 @@ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License
  You should have received a copy of the GNU General Public License
  along with GCC; see the file COPYING3.  If not see
  <http://www.gnu.org/licenses/>.  */
+#include 
  
  #ifndef GCC_SSA_ITERATORS_H

  #define GCC_SSA_ITERATORS_H
@@ -68,6 +69,10 @@ struct imm_use_iterator
ssa_use_operand_t *next_imm_name;
  };
  
+/*IMM Iterator Mutex*/

+pthread_mutex_t imm_iteration_mutex;
+/*IMM_STMT Iterator Mutex*/
+pthread_mutex_t imm_stmt_iterator_mutex;
  
  /* Use this iterator when simply looking at stmts.  Adding, deleting or

 modifying stmts will cause this iterator to malfunction.  */
@@ -82,7 +87,7 @@ struct imm_use_iterator
  #define FOR_EACH_IMM_USE_STMT(STMT, ITER, SSAVAR) \
for ((STMT) = first_imm_use_stmt (&(ITER), (SSAVAR));   \
 !end_imm_use_stmt_p (&(ITER)); \
-   (void) ((STMT) = next_imm_use_stmt (&(ITER
+   (void) ((STMT) = next_imm_use_stmt (&(ITER   \
  
  /* Use this to terminate the FOR_EACH_IMM_USE_STMT loop early.  Failure to

 do so will result in leaving a iterator marker node in the immediate
@@ -116,7 +121,7 @@ struct imm_use_iterator
  #define FOR_EACH_IMM_USE_ON_STMT(DEST, ITER)  \
for ((DEST) = first_imm_use_on_stmt (&(ITER));  \
 !end_imm_use_on_stmt_p (&(ITER));  \
-   (void) ((DEST) = next_imm_use_on_stmt (&(ITER
+   (void) ((DEST) = next_imm_use_on_stmt (&(ITER\
  
  
  
@@ -147,6 +152,13 @@ struct ssa_op_iter

gimple *stmt;
  };
  
+/*SSA Iterator Mutex*/

+pthread_mutex_t ssa_iteration_mutex;
+/*PHI Iterator Mutex*/
+pthread_mutex_t phi_iteration_mutex;
+/*PHI_STMT Iterator Mutex*/
+pthread_mutex_t phi_stmt_iterator_mutex;
+
  /* NOTE: Keep these in sync with doc/tree-ssa.texi.  */
  /* These flags are used to determine which operands are returned during
 execution of the loop.  */
@@ -168,7 +180,7 @@ struct ssa_op_iter
  #define FOR_EACH_SSA_TREE_OPERAND(TREEVAR, STMT, ITER, FLAGS) \
for (TREEVAR = op_iter_init_tree (&(ITER), STMT, FLAGS);\
 !op_iter_done (&(ITER));   \
-   (void) (TREEVAR = op_iter_next_tree (&(ITER
+   (void) (TREEVAR = op_iter_next_tree (&(ITER  \
  
  /* This macro executes a loop over the operands of STMT specified in FLAG,

 returning each operand as a 'use_operand_p' in the variable USEVAR.
@@ -176,7 +188,7 @@ struct ssa_op_iter
  #define FOR_EACH_SSA_USE_OPERAND(USEVAR, STMT, ITER, FLAGS)   \
for (USEVAR = op_iter_init_use (&(ITER), STMT, FLAGS);  \
 !op_iter_done (&(ITER));   \
-   USEVAR = op_iter_next_use (&(ITER)))
+   USEVAR = op_iter_next_use (&(ITER))) \
  
  /* This macro executes a loop over the operands of STMT specified in FLAG,

 returning each operand as a 'def_operand_p' in the variable DEFVAR.
@@ -184,7 +196,7 @@ struct ssa_op_iter
  #define FOR_EACH_SSA_DEF_OPERAND(DEFVAR, STMT, ITER, FLAGS)   \
for (DEFVAR = op_iter_init_def (&(ITER), STMT, FLAGS);  \
 !op_iter_done (&(ITER));   \
-   DEFVAR = op_iter_next_def (&(ITER)))
+   DEFVAR = op_iter_next_def (&(ITER))) \
  
  /* This macro will execute a loop over all the arguments of a PHI which

 match FLAGS.   A use_operand_p is always returned via USEVAR.  FLAGS
@@ -192,7 +204,7 @@ struct ssa_op_iter
  #define FOR_EA

Question about Walking Compilation Tree in pass_manager.h

[Nicholas Krause]

Greetings,

Thanks for being patient with me as I figure out where to start but 
seems here is a good place:

+  /*TODO Walk Pass with Threads*/
+  void walk_small_ipa_passes(function *fun) {
+   while(all_small_ipa_passes != NULL) {
+   all_small_passes->execute(fun);
+    all_small_ipa_passes = all_small_ipa_passes->next;
+   }
+  }
+  /*TODO Walk Pass with Threads*/
+  void walk_regular_ipa_passes(function *fun) {
+   while(all_regular_ipa_passes != NULL) {
+   all_regular_passes->execute(fun);
+    all_regular_ipa_passes = all_small_ipa_passes->next;
+   }
+  }
+  /*TODO Walk Pass with Threads*/
+  void walk_late_ipa_passes(function *fun) {
+   while(all_small_ipa_passes != NULL) {
+   all_late_passes->execute(fun);
+    all_late_ipa_passes = all_small_ipa_passes->next;
+   }

These are a set of functions that can or should walk the root downward 
and execute a pass
on the given function passed in and would be launched in async. I'm a 
few questions about

doing this:

1. Is this safe in terms of a particular pass type running all of its 
passes in linear and not
reordering. Seems so after reading pass.def but not sure if that's 
correct or something

can reorder passes elsewhere. I'm assuming not.

2.  The core pass manager class has very few callers and the only I'm 
noticing with  grep
are in cgraph or other such files. I'm wondering how to call these 
functions from callers
on a per function basis. Seems the best thing is to insert them at the 
beginning of the
pass manager execute per function.  There doesn't seem to be a place for 
this outside
of pass.def. So no idea if we need to inject a parent pass for all 
passes to do this. I would

prefer not to do so for but it seems the only way.

3. Not sure how to do this for gimple or rtl as those are not declared 
as a opt_pass
root node for tree.  Is this assumed for a reason as the manual nor the 
code mentions

why ipa passes are root nodes but not gimple or rtl.

Thanks and I'm aware of the gate version that would be required as well 
to only

execute if true,
Nick

Status of C++11 Move and Using Unique_Ptr

[Nicholas Krause]

Greetings Jeff,

Sorry if I'm bugging you. I've already sent off some work on IPA passes 
with a few questions here:

https://gcc.gnu.org/ml/gcc/2020-02/msg00247.html

And locking SSA iterators:

From: Nicholas Krause

In order to start making SSA be muti-threaded safe I'm proposing
adding locks as implemented in this patch. There are two ways
of doing the locking and both have there advantage/disadvantage:
1.Rewrite the marcos to be functions and make the locking internal
to SSA iterators themselves. This removes possible inlining of the
marcos as currently implemented.
2. Don't change the marcos but add the proposed locks and update
the manual to warn about locking/unlocking the correct lock or
series of locks when iterating over SSA or other similar nodes.

Not sure which is better. Comments are also welcome.
Signed-off-by: Nicholas Krause
---
 gcc/ssa-iterators.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/ssa-iterators.h b/gcc/ssa-iterators.h
index 65d8e3b..1c8c2ad 100644
--- a/gcc/ssa-iterators.h
+++ b/gcc/ssa-iterators.h
@@ -16,11 +16,11 @@ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General 
Public License
 You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 <http://www.gnu.org/licenses/>.  */
-#include 
 
 #ifndef GCC_SSA_ITERATORS_H

 #define GCC_SSA_ITERATORS_H
 
+#include 

 /* Immediate use lists are used to directly access all uses for an SSA
name and get pointers to the statement for each use.
 
@@ -70,9 +70,9 @@ struct imm_use_iterator

 };
 
 /*IMM Iterator Mutex*/

-pthread_mutex_t imm_iteration_mutex;
+extern pthread_mutex_t imm_iteration_mutex;
 /*IMM_STMT Iterator Mutex*/
-pthread_mutex_t imm_stmt_iterator_mutex;
+extern pthread_mutex_t imm_stmt_iterator_mutex;
 
 /* Use this iterator when simply looking at stmts.  Adding, deleting or

modifying stmts will cause this iterator to malfunction.  */
@@ -153,11 +153,11 @@ struct ssa_op_iter
 };
 
 /*SSA Iterator Mutex*/

-pthread_mutex_t ssa_iteration_mutex;
+extern pthread_mutex_t ssa_iteration_mutex;
 /*PHI Iterator Mutex*/
-pthread_mutex_t phi_iteration_mutex;
+extern pthread_mutex_t phi_iteration_mutex;
 /*PHI_STMT Iterator Mutex*/
-pthread_mutex_t phi_stmt_iterator_mutex;
+extern pthread_mutex_t phi_stmt_iterator_mutex;
 
 /* NOTE: Keep these in sync with doc/tree-ssa.texi.  */

 /* These flags are used to determine which operands are returned during
-- 1.8.3.1



I was wondering and maybe its a dumb idea but seems removing the garbage 
collector for the most
part is going to be possible and I'm going to investigate into it 
further this week.


Seems that GTY() wrappers are really just one of two use cases after 
looking through a few

files:
Empty Wrappers that don't have a pointer can just be removed due to them 
now allocating
memory themselves  but callers doing so. Or the second case of having a 
pointer(s) which

need a destructor for them.

However for the other wrappers which take arguments I was wondering if 
its possible to
just use unique_ptr with a custom allocater. Seems that's basically what 
the internal
garbage collector is. I'm not sure of the current status of the C++11 
move and sorry

if I did not help out as much with that under than the early discussion.


Take care,
Nick

[PATCH] Add missing noexpect causes in tuple for move functions

[Nicholas Krause]

This adds the remainging noexcept causes required for this cause
to meet the spec as dicussed last year and documented here:
http://cplusplus.github.io/LWG/lwg-active.html#2899.

Signed-off-by: Nicholas Krause 
---
 libstdc++-v3/include/std/tuple | 4 
 1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 56b97c25eed..d17512a1b7e 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -214,6 +214,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if::type>
 explicit
 constexpr _Tuple_impl(_UHead&& __head, _UTail&&... __tail)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::forward<_UTail>(__tail)...),
  _Base(std::forward<_UHead>(__head)) { }
 
@@ -237,6 +239,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 constexpr _Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
+noexcept(__and_,
+ is_nothrow_move_constructible<_Inherited>>::value)
: _Inherited(std::move
 (_Tuple_impl<_Idx, _UHead, _UTails...>::_M_tail(__in))),
  _Base(std::forward<_UHead>
-- 
2.17.1

[PATCH] Proposed patch to fix bug id, 89796 on bugzilla

[Nicholas Krause]

Not sure if this is a correct fix to this bug found here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
comments are welcome. If a backtrace is required please
let me know. I am just sending it to the development list
for review to make sure it's OK in terms of my understanding
the code.

Signed-off-by: Nicholas Krause 
---
 gcc/cp/constraint.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 9884eb0db50..a78d0a9a49b 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1882,7 +1882,7 @@ tsubst_requires_expr (tree t, tree args,
   tree parms = TREE_OPERAND (t, 0);
   if (parms)
 {
-  parms = tsubst_constraint_variables (parms, args, complain, in_decl);
+  parms = tsubst_constraint_variables (PARM_CONSTR_PARMS (parms), args, 
complain, in_decl);
   if (parms == error_mark_node)
 return error_mark_node;
 }
-- 
2.17.1

Re: add command line option to gcc

[Nicholas Krause]

On 9/5/19 11:25 PM, Tim Rice wrote:

I have a use case where I would like gcc to accept -Kthread
and act as if it was passed -pthread. So -Kthread would
be a synonym for -pthread.

I am having trouble figuring out how the option processing is handled.
Possibly in gcc/gcc.c but I am stumped here.

Any pointers would be welcome.

Thanks.



The first thing is why don't you just create a alias in your shell for 
this. If not


you also have to understand -lpthread is a linker to link in the 
library. If you


really require to do then you will need to rewrite parts of the C++/C 
frontends.


Here is a link to what you will need to read:

https://gcc.gnu.org/onlinedocs/gccint/Front-End.html#Front-End

Mostly it's adding the option so the first link should help it seems for 
understanding


a frontend directory,


Nick

Enabling Ctags Tree Wide for GCC

[Nicholas Krause]

Greetings,

I was wondering what is the easiest way to allow source tree wide ctags. 
There doesn't


seem to be a make x command for it nor any real documentation online and 
it would


be nice to have.


Thanks,

Nick

Re: Enabling Ctags Tree Wide for GCC

[Nicholas Krause]

On 9/11/19 2:30 AM, Andreas Schwab wrote:

On Sep 11 2019, Nicholas Krause  wrote:


I was wondering what is the easiest way to allow source tree wide
ctags.

There is make TAGS, which uses etags.

Andreas.


Andreas,


Is there no way to build it for vim as thats what I would prefer to stay 
with.



Anyhow thanks,


Nick

[PATCH] RFC: Start discussion on class or classes for thread data in GCC multithreading effort

[Nicholas Krause]

From: npkrause 

This is not meant to be merged nor follow any GCC coding standards
but start the work discussed about multithreading GCC. The dicussion
or part of it is about using per thread versions of the shared
data structures. However this runs into three issues to my knowledge
and therefore need to be dicussed. Some of this was discussed at
Cauldron but Richard was not there so I would like his comments.
1. Stack Size in the pthread spec seems to be a limit of 16K but
can we assume more to allocate the rather large structures into the
thread TLS.
2. Does the data need to be around per GIMPLE passes or for the
whole compilation as if not I would suggest a set of different
classes per GIMPLE,RTL phases.
3. Are the data structures immutable outside of the creation of
the data or do we need to be able to change the data on the fly?

Signed-off-by: npkrause 
---
 gcc/thread-data.c |  8 
 gcc/thread-data.h | 28 
 2 files changed, 36 insertions(+)
 create mode 100644 gcc/thread-data.c
 create mode 100644 gcc/thread-data.h

diff --git a/gcc/thread-data.c b/gcc/thread-data.c
new file mode 100644
index 000..d0fe4c5d511
--- /dev/null
+++ b/gcc/thread-data.c
@@ -0,0 +1,8 @@
+#include "thread-data.h"
+
+ThreadData::ThreadData() {
+
+}
+
+ThreadData::~ThreadData() {
+}
diff --git a/gcc/thread-data.h b/gcc/thread-data.h
new file mode 100644
index 000..0c83846d046
--- /dev/null
+++ b/gcc/thread-data.h
@@ -0,0 +1,28 @@
+/* thread-data.h - Various declarations for data structures to be lauched
+   per thread as found in thread-data.c
+   Copyright (C) 1998-2019 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef GCC_THREAD_DATA_H
+#define GCC_THREAD_DATA_H
+
+class ThreadData {
+   public:
+   ThreadData();
+   ~ThreadData();
+}
-- 
2.20.1

Multi-Threading GCC Compiler Internal Data

[Nicholas Krause]

Greetings Richard,

I don't know if it's currently possible but whats the best way to either 
so about or


use a tool to expose shared state at both the GIMPLE and RTL level.  
This would


allow us to figure out much better what algorthims or data structures to 
choose


to allow this to scale much better than the current prototype.


Thanks,


Nick

Re: Multi-Threading GCC Compiler Internal Data

[Nicholas Krause]

On 9/17/19 2:37 AM, Richard Biener wrote:

On Mon, 16 Sep 2019, Nicholas Krause wrote:


Greetings Richard,

I don't know if it's currently possible but whats the best way to either so
about or

use a tool to expose shared state at both the GIMPLE and RTL level.  This
would

allow us to figure out much better what algorthims or data structures to
choose

to allow this to scale much better than the current prototype.

You are mixing independent issues.  Shared state needs to be identified
and protected for correctness reasons.  In some cases changing the
data structure to be protected can make it cheaper to do so.  The
scaling of the current prototype is limited by the fraction of the
compilation we parallelize as well as the granularity.

Going forward the most useful things are a) reducing the amount of
state that ends up being shared when we paralellize, b) increase
the fraction of the compilation we paralellize by tackling
RTL optimizations and the early GIMPLE pipeline

The prototype showed that paralellization is beneficial and that it
can be done with a reasonable amount of work.

Richard.


Richard,

Sorry I think your misunderstanding me. I was asking whats the best way to

write a tool to expose twhere and how the shared state is using being used.

As from experience it seems  the best way forward is to figure out what

we have in terms of shared state and write a core set of classes or API \

for scaling the shared  state. If we have a tool for collecting data 
this would


be much easier.

My reasoning for this is threefold:

1. It removes the issues with each pass needing be scaled seperately

2. It allows us to deal with future added passes being able to be 
palleralized


3.  Allows us to get data about scaling from other jobs like make -j without

issues and as the user would assume it worked. This was discussed at 
Cauldron


and other people seem to agree that working well with make is a good idea.

Hopefully that explains it better,

Nick

Re: Multi-Threading GCC Compiler Internal Data

[Nicholas Krause]

On 9/18/19 4:01 AM, Richard Biener wrote:

On Tue, 17 Sep 2019, Nicholas Krause wrote:


On 9/17/19 2:37 AM, Richard Biener wrote:

On Mon, 16 Sep 2019, Nicholas Krause wrote:


Greetings Richard,

I don't know if it's currently possible but whats the best way to either so
about or

use a tool to expose shared state at both the GIMPLE and RTL level.  This
would

allow us to figure out much better what algorthims or data structures to
choose

to allow this to scale much better than the current prototype.

You are mixing independent issues.  Shared state needs to be identified
and protected for correctness reasons.  In some cases changing the
data structure to be protected can make it cheaper to do so.  The
scaling of the current prototype is limited by the fraction of the
compilation we parallelize as well as the granularity.

Going forward the most useful things are a) reducing the amount of
state that ends up being shared when we paralellize, b) increase
the fraction of the compilation we paralellize by tackling
RTL optimizations and the early GIMPLE pipeline

The prototype showed that paralellization is beneficial and that it
can be done with a reasonable amount of work.

Richard.


Richard,

Sorry I think your misunderstanding me. I was asking whats the best way to

write a tool to expose twhere and how the shared state is using being used.

Such tool would need to solve the halting problem so it cannot exist.

Richard.


I figured but is it still possible to get the data out of perf if 
possible. Not sure


what the best way to get the data for GCC directly is or out of around 
profiler


as I assuming even just splitting out some of the larger GIMPLE functions as

a start may help. So what tools or ways are the easiest to profile make -jx

to your knowledge.

Thats where I starting to profile or get real data for the work,


Nick

Updating Makefile to Allow Profiling of GCC Internals

[Nicholas Krause]

Greetings,

I'm not as familar of the currrent Makefile internals for GCC, so what 
is the best


way to add -pg for profiling. Seems I need to add it for gprof in order 
to get


some real data for multi-threading GCC internals.

Thanks,

NIck

Atomics in C++11

[Nicholas Krause]

Greetings,

I was wondering if its possible to use the C11 atomics library for 
multithreading


GCC. Not sure if its a good idea due to concerns about older plaforms 
not having


a C11 supported libraries or compiler.

If not then the best way is pthreads key support and other posix thread 
supports.


Thanks,

Nick

Re: Atomics in C++11

[Nicholas Krause]

On 9/20/19 4:09 PM, Jason Merrill wrote:

On Fri, Sep 20, 2019 at 8:32 AM Nicholas Krause  wrote:

I was wondering if its possible to use the C11 atomics library for
multithreading

GCC. Not sure if its a good idea due to concerns about older plaforms
not having a C11 supported libraries or compiler.

I've been wondering if it's time to move to C++11 in general, since
we've had compilers with C++11 support for more than 5 years at this
point.

Jason


Jason,

It's up to the community at large but both me and the other student who 
is CCed


on this work would find it useful. He wants to use TLS for certain 
structures and


functions to be doubled per thread for no locking e.t.c. and ease of 
programming.



He can add his comments if need be,

Nick

Re: Atomics in C++11

[Nicholas Krause]

On 9/20/19 4:43 PM, Joel Sherrill wrote:

On Fri, Sep 20, 2019, 3:12 PM Nicholas Krause  wrote:


On 9/20/19 4:09 PM, Jason Merrill wrote:

On Fri, Sep 20, 2019 at 8:32 AM Nicholas Krause 

wrote:

I was wondering if its possible to use the C11 atomics library for
multithreading

GCC. Not sure if its a good idea due to concerns about older plaforms
not having a C11 supported libraries or compiler.

I've been wondering if it's time to move to C++11 in general, since
we've had compilers with C++11 support for more than 5 years at this
point.

Jason


Jason,

It's up to the community at large but both me and the other student who
is CCed

on this work would find it useful. He wants to use TLS for certain
structures and

functions to be doubled per thread for no locking e.t.c. and ease of
programming.


When I reviewed TLS support for all RTEMS targets, it wasn't clear that TLS
ABI is defined for all supported GCC architectures or that it was
universally supported by the backends.

I'm not questioning the value of TLS. I'm just wanting to make sure all GCC
targets actually support TLS.

I may have missed a default generic implementation. It is really hard to
find ABI info for all pro processors.

I would be thrilled to learn I missed the default generic implementation.
This would make supporting it across the 18 architectures RTEMS supports
much easier. :)


Seems its using IA-64 ABI as reported in a  older manual here:

https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html

Nick



He can add his comments if need be,

Nick

SSA Trees and Making them MultiThreaded Aware

[Nicholas Krause]

Richard,

Sorry for the second email but I forget in the previous one but Jeff Law 
at Cauldron stated


your the expert for the SSA code. Is it possible to make that code 
multithreaded in particular


the dominator trees.

I'm going to start researching that as Giuliano's branch does not build 
seems he removed


the Pthreads flag in the makefile(s). I've already opened a issue with 
him to fix that.



Nick

Seg Fault in GCC When Building

[Nicholas Krause]

Greetings,

For the last several days the branch for multithreading in GSOC does not 
build and


crashes like so:

make[4]: Leaving directory 
`/home/xerofoify/GCC/powerpc64le-unknown-linux-gnu/libquadmath'
make[3]: Leaving directory 
`/home/xerofoify/GCC/powerpc64le-unknown-linux-gnu/libquadmath'
make[2]: Leaving directory 
`/home/xerofoify/GCC/powerpc64le-unknown-linux-gnu/libquadmath'

during RTL pass: expand
../../../../../threads/libstdc++-v3/src/c++98/istream-string.cc: In 
function ‘std::basic_istream<_CharT, _Traits>& 
std::getline(std::basic_istream<_CharT, _Traits>&, 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&, _CharT) [with 
_CharT = char; _Traits = std::char_traits; _Alloc = 
std::allocator]’:
../../../../../threads/libstdc++-v3/src/c++98/istream-string.cc:122:5: 
internal compiler error: Segmentation fault

  122 | getline(basic_istream& __in, basic_string& __str,
  | ^~~
during RTL pass: expand
monetary_members.cc: In member function ‘void 
std::__cxx11::moneypunct<_CharT, 
_Intl>::_M_initialize_moneypunct(std::__c_locale, const char*) [with 
_CharT = char; bool _Intl = false]’:

monetary_members.cc:370:5: internal compiler error: Segmentation fault
  370 | moneypunctfalse>::_M_initialize_moneypunct(__c_locale __cloc,

  | ^~~
during RTL pass: expand
In file included from 
../../../../../threads/libstdc++-v3/src/c++98/cow-istream-string.cc:30:
../../../../../threads/libstdc++-v3/src/c++98/istream-string.cc: In 
function ‘std::basic_istream<_CharT, _Traits>& 
std::getline(std::basic_istream<_CharT, _Traits>&, 
std::basic_string<_CharT, _Traits, _Alloc>&, _CharT) [with _CharT = 
char; _Traits = std::char_traits; _Alloc = std::allocator]’:
../../../../../threads/libstdc++-v3/src/c++98/istream-string.cc:122:5: 
internal compiler error: Segmentation fault

  122 | getline(basic_istream& __in, basic_string& __str,
  | ^~~
during RTL pass: expand
monetary_members_cow.cc: In member function ‘void 
std::moneypunct<_CharT, 
_Intl>::_M_initialize_moneypunct(std::__c_locale, const char*) [with 
_CharT = char; bool _Intl = true]’:

monetary_members_cow.cc:214:5: internal compiler error: Segmentation fault
  214 | moneypunct::_M_initialize_moneypunct(__c_locale 
__cloc,

  | ^~
0x10c476b3 crash_signal
    ../../threads/gcc/toplev.c:326
0x10794750 test
    ../../threads/gcc/rtl.h:880
0x10794750 is_a
    ../../threads/gcc/is-a.h:187
0x10794750 safe_as_a
    ../../threads/gcc/is-a.h:210
0x10794750 PREV_INSN
    ../../threads/gcc/rtl.h:1449
0x10794750 add_insn_before_nobb
    ../../threads/gcc/emit-rtl.c:4205
0x1079d46f add_insn_before(rtx_insn*, rtx_insn*, basic_block_def*)
    ../../threads/gcc/emit-rtl.c:4264
0x1079e703 emit_note_before(insn_note, rtx_insn*)
    ../../threads/gcc/emit-rtl.c:4832
0x1066cbe3 create_basic_block_structure(rtx_insn*, rtx_insn*, rtx_note*, 
basic_block_def*)

    ../../threads/gcc/cfgrtl.c:316
0x1066cf43 rtl_create_basic_block
    ../../threads/gcc/cfgrtl.c:370
0x1064a6df create_basic_block_1
    ../../threads/gcc/cfghooks.c:718
0x10667e1b rtl_split_edge
    ../../threads/gcc/cfgrtl.c:1908
0x1064c323 split_edge(edge_def*)
    ../../threads/gcc/cfghooks.c:648
0x10d46e73 expand_phi_nodes(ssaexpand*)
    ../../threads/gcc/tree-outof-ssa.c:1009
0x10c476b3 crash_signal
    ../../threads/gcc/toplev.c:326
0x1064753b execute
    ../../threads/gcc/cfgexpand.c:6495
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
0x10794750 test
    ../../threads/gcc/rtl.h:880
0x10794750 is_a
    ../../threads/gcc/is-a.h:187
0x10794750 safe_as_a
    ../../threads/gcc/is-a.h:210
0x10794750 PREV_INSN
    ../../threads/gcc/rtl.h:1449
0x10794750 add_insn_before_nobb
    ../../threads/gcc/emit-rtl.c:4205
0x1079d46f add_insn_before(rtx_insn*, rtx_insn*, basic_block_def*)
    ../../threads/gcc/emit-rtl.c:4264
0x1079e703 emit_note_before(insn_note, rtx_insn*)
    ../../threads/gcc/emit-rtl.c:4832
make[5]: *** [istream-string.lo] Error 1
make[5]: *** Waiting for unfinished jobs
0x1066cbe3 create_basic_block_structure(rtx_insn*, rtx_insn*, rtx_note*, 
basic_block_def*)

    ../../threads/gcc/cfgrtl.c:316
0x1066cf43 rtl_create_basic_block
    ../../threads/gcc/cfgrtl.c:370
0x1064a6df create_basic_block_1
    ../../threads/gcc/cfghooks.c:718
0x10667e1b rtl_split_edge
    ../../threads/gcc/cfgrtl.c:1908
0x1064c323 split_edge(edge_def*)
    ../../threads/gcc/cfghooks.c:648
0x10d46e73 expand_phi_nodes(ssaexpand*)
    ../../threads/gcc/tree-outof-ssa.c:1009
0x10c476b3 crash_signal
    ../../threads/gcc/toplev.c:326
0x10794750 test
    ../../threads/gcc/rtl.h:880
0x10794750 is_a
    ../../threads/gcc/is-a.h:187
0x10794750 safe_as_a
    ../../threads/gcc/is-a.h:210
0x10794750 PREV_INSN
    ../../threads/gcc/rtl.h:1449
0x10794750 add_insn_before_nobb
    ../../threads/gcc/emit-rtl.c:

Moving to C++11

[Nicholas Krause]

Greetings,

I asked about moving to C/C++ 11 as it would make it easier to

allow multithreading support due to having a memory model

alongside other features. Jason Merill mentioned due to it

being so common it may be a good  time to.

Moving to git seems to be universally agree on so I'm opening the discussion

for the same as related to C/C++11 migration and if possible opening

a TODO similar to git if decided on.

Please post your comments or ideas about the migration in response to this

email,

Nick

Re: Moving to C++11

[Nicholas Krause]

On 9/26/19 4:08 AM, Richard Biener wrote:

On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely  wrote:

On Thu, 26 Sep 2019, 05:10 Nicholas Krause,  wrote:

Greetings,

I asked about moving to C/C++ 11 as it would make it easier to

allow multithreading support due to having a memory model

alongside other features. Jason Merill mentioned due to it

being so common it may be a good  time to.

Moving to git seems to be universally agree on so I'm opening the discussion

for the same as related to C/C++11 migration and if possible opening

a TODO similar to git if decided on.

Please post your comments or ideas about the migration in response to this

email,



For a start, it doesn't make sense to talk about C/C++11.

C and C++ are separate languages, and so are C11 and C++11. There is
no reason why using C++11 should imply using C11, let's not confuse
things.

GCC is written in C++ so the topic should be C++11.

Note the main issue is host compiler support.  I'm not sure if C++11 would
be the step we'd gain most - for some hashtable issues I'd have needed
std::move support for example.  There's always the possibility to
require an intermediate step (first build GCC 5, with that you can build
trunk, etc.), a install.texi clarification could be useful here (or even
some automation via a contrib/ script).

I agree.


I'm not too worried about requiring even a C++14 compiler, for the
set of products we still release latest compilers we have newer
GCCs available we can use for building them (even if those are
not our primary supported compilers which would limit us to
GCC 4.8).
Note I'd still not like to see more C++ feature creep into general
non-container/infrastructure code, C++ is complex enough as-is.


While the features that  seem to be the most useful to use I will

list below:

1. C++ memory model and atomics classes

2. Move and R values

3. Auto?

4. For each loops may be nice i.e. x: array loops through all of the array

To your point it seems that the above are the most useful and we can

just avoid the others as these don't really affect core code and even

if they do its an extension rather of older features. Auto is just

templates for variables really.

Nick




Richard.

Moving to C++11

[Nicholas Krause]

Greetings David,

I posted on the list about moving to C++11/C11 but the focus was on

C++11 for my work. Seems that other people wanted to use some

parts of the C++11 standard including rvalues,move,auto and template

aliases. The thread is here:

https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html

I've come to the conclusion that enabling parts of it would be useful 
overall based


on the linked discussion.

Therefore I'm opening up the discussion again with the commitee involved 
to figure


out what should be used and how the migration should take place,

Nick

Moving to C++11

[Nicholas Krause]

Greetings Jonathan and Jason,

I was wondering what work is required to move to C++11. Seems your

both interested in getting this done and so am I. Perhaps we start

similar to Git with a wiki page about what features would be useful

and then start migrating the makefiles to allow for this.

So far according to the previous discussion it seems that the community

would like these features:

1. Template Aliases

2. Better narrowing supprot for core types

2. Auto for local variables

3. std::move,rvalues

4. For each loops

Let me know if I missed something but I will be glad to help out with this,

Nick

PING:Re: Moving to C++11

[Nicholas Krause]

On 9/30/19 1:50 PM, Nicholas Krause wrote:

Greetings Jonathan and Jason,

I was wondering what work is required to move to C++11. Seems your

both interested in getting this done and so am I. Perhaps we start

similar to Git with a wiki page about what features would be useful

and then start migrating the makefiles to allow for this.

So far according to the previous discussion it seems that the community

would like these features:

1. Template Aliases

2. Better narrowing supprot for core types

2. Auto for local variables

3. std::move,rvalues

4. For each loops

Let me know if I missed something but I will be glad to help out with 
this,


Nick

Just pinging this as I've not heard any replies.

Nick

Parallel GCC Testing

[Nicholas Krause]

Greetings,

I've one of the students who is working on the project. I'm just posting to

continue the discussion on C++11 migration for async and memory model

support alongside other features people want. In addition the secondary

part of this email is that the other student mentioned at Cauldron testing

lots of packages would be a issue, and seems not due tothe Yocto Project:

https://www.yoctoproject.org/

The projects build software packages at a singular level as bitbake 
recipe_name


and therefore I'm suggesting comments on if linking a custom toolchain

to it for testing would be a good idea. We are no where near this but

it would be nice to get some comments on using it for building other

software/testing it.

I've also in the process of trying to figure out what queueing strategy 
for RTL


and GIMPLE scales best as we may be able to get pass ideal scaling at 
four threads


with better threading queueing of the passes.

Any comments or questions are welcome,

Nick

Yocto Project Recipe for Testing upstream code

[Nicholas Krause]

Greetings David,

I mentioned this in my other email for my work but it seems that the Yocto

Project has this recipe devupstream.bbclass and are hoping to get it to

work for upstream code including gcc from HEAD e.t.c.  I'm asked them

to see if they can mention that other projects like LLVM/GCC may want

to have this as well at there usual yearly meeting at the usual yearly

Embedded Linux/IOT conference.

I'm assuming you are aware of the project but if 
not:https://www.yoctoproject.org/



This would allow us to not only have a testsuite but a toolkit that 
builds real


software. Here is a list of all the software that is supported:

https://layers.openembedded.org/layerindex/branch/master/layers/

Layers are just containers so you can look at recipes for all the 
packages that it


can build when testing an external toolchain in this case, upstream.

They seem to think its a good idea so I'm sharing on this end with the 
GCC folks


and its highly automated with bitbake which is even better,

Nick

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/18/19 12:20 PM, Nicholas Krause wrote:


On 11/18/19 12:11 PM, Segher Boessenkool wrote:

Hi Richard,

On Mon, Nov 18, 2019 at 04:48:03PM +, Richard Earnshaw (lists) 
wrote:

On 18/11/2019 15:55, Segher Boessenkool wrote:

That immediately shows some of the shortcomings of this approach: the
subject line is much too long, but more importantly, it doesn't make
much sense: it is not what the patch does, it is the description of a
bug that is related in some way to this patch.  It is not uncommon for
a commit to not fix the problem mentioned in the bug report (if it 
*is*

a problem!), or not fix it completely.

Then again, changing all such subject lines to read "patch" could also
already be considered an improvement.

Well the real question is whether such a summary is worse than the
current situation of just printing the author in the wrong field.  I
personally don't think it is.

I think that non-obviously-wrong-but-still-wrong info is not something
we should introduce.  And, I think this will happen a *lot*.

Maybe you can just put in artificial subjects like "Patch related to
PR12345" or the like?  That is correct, displays a lot better, and is
at least as useful (imo).


I don't see but other projects  mention PRS or Bugzilla ids but

more common in my experience is just mentioned the commit

ids. For example this fixes commit id x introducing PR x. Commit

ids are know good so having them linked in commit messages

is much easier to track then PRs, I can just use git log -p commit id.




There are about 560 commits where the code highlights that the data
might be suspect (usually a category mismatch).

What about commits that mention multiple PRs?  What do you do for those?
(Are there as many of those as I think, anyway?)  With normally very 
short

subjects you could put all of them in there :-)


See my above but for this you would just state the main issue(s) in 
the commit


message and in the body what commits/PRs are being handled.

Not sure if that works for everyone but that's normally the best way 
in my


experience,

Nick

Sorry but cced the others as this was a misclick.


Segher

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/18/19 12:23 PM, Nicholas Krause wrote:


On 11/18/19 12:20 PM, Nicholas Krause wrote:


On 11/18/19 12:11 PM, Segher Boessenkool wrote:

Hi Richard,

On Mon, Nov 18, 2019 at 04:48:03PM +, Richard Earnshaw (lists) 
wrote:

On 18/11/2019 15:55, Segher Boessenkool wrote:

That immediately shows some of the shortcomings of this approach: the
subject line is much too long, but more importantly, it doesn't make
much sense: it is not what the patch does, it is the description of a
bug that is related in some way to this patch.  It is not uncommon 
for
a commit to not fix the problem mentioned in the bug report (if it 
*is*

a problem!), or not fix it completely.

Then again, changing all such subject lines to read "patch" could 
also

already be considered an improvement.

Well the real question is whether such a summary is worse than the
current situation of just printing the author in the wrong field.  I
personally don't think it is.

I think that non-obviously-wrong-but-still-wrong info is not something
we should introduce.  And, I think this will happen a *lot*.

Maybe you can just put in artificial subjects like "Patch related to
PR12345" or the like?  That is correct, displays a lot better, and is
at least as useful (imo).


I don't see but other projects  mention PRS or Bugzilla ids but

more common in my experience is just mentioned the commit

ids. For example this fixes commit id x introducing PR x. Commit

ids are know good so having them linked in commit messages

is much easier to track then PRs, I can just use git log -p commit id.




There are about 560 commits where the code highlights that the data
might be suspect (usually a category mismatch).
What about commits that mention multiple PRs?  What do you do for 
those?
(Are there as many of those as I think, anyway?)  With normally very 
short

subjects you could put all of them in there :-)


See my above but for this you would just state the main issue(s) in 
the commit


message and in the body what commits/PRs are being handled.

Not sure if that works for everyone but that's normally the best way 
in my


experience,

Nick

Sorry but cced the others as this was a misclick.


One of the emails CCed was boucing so I just fixed that as well.

Nick





Segher

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/18/19 12:46 PM, Richard Earnshaw (lists) wrote:

On 18/11/2019 17:25, Nicholas Krause wrote:


On 11/18/19 12:23 PM, Nicholas Krause wrote:


On 11/18/19 12:20 PM, Nicholas Krause wrote:


On 11/18/19 12:11 PM, Segher Boessenkool wrote:

Hi Richard,

On Mon, Nov 18, 2019 at 04:48:03PM +, Richard Earnshaw (lists) 
wrote:

On 18/11/2019 15:55, Segher Boessenkool wrote:
That immediately shows some of the shortcomings of this 
approach: the
subject line is much too long, but more importantly, it doesn't 
make
much sense: it is not what the patch does, it is the description 
of a
bug that is related in some way to this patch.  It is not 
uncommon for
a commit to not fix the problem mentioned in the bug report (if 
it *is*

a problem!), or not fix it completely.

Then again, changing all such subject lines to read "patch" 
could also

already be considered an improvement.

Well the real question is whether such a summary is worse than the
current situation of just printing the author in the wrong field.  I
personally don't think it is.
I think that non-obviously-wrong-but-still-wrong info is not 
something

we should introduce.  And, I think this will happen a *lot*.

Maybe you can just put in artificial subjects like "Patch related to
PR12345" or the like?  That is correct, displays a lot better, and is
at least as useful (imo).


I don't see but other projects  mention PRS or Bugzilla ids but

more common in my experience is just mentioned the commit

ids. For example this fixes commit id x introducing PR x. Commit

ids are know good so having them linked in commit messages

is much easier to track then PRs, I can just use git log -p commit id.




There are about 560 commits where the code highlights that the data
might be suspect (usually a category mismatch).
What about commits that mention multiple PRs?  What do you do for 
those?
(Are there as many of those as I think, anyway?)  With normally 
very short

subjects you could put all of them in there :-)


See my above but for this you would just state the main issue(s) in 
the commit


message and in the body what commits/PRs are being handled.

Not sure if that works for everyone but that's normally the best 
way in my


experience,

Nick

Sorry but cced the others as this was a misclick.


One of the emails CCed was boucing so I just fixed that as well.



[strange, I'm not seeing bounces].


Nick





Segher


SVN commit Ids can't be fixed here.  Not least because we don't know 
the SHA code for the git commit at this point.  For legacy commit id's 
we'll just need to keep the existing SVN repo available, so that folks 
can look at it with, say, viewcvs.


R.


Richard,

That's a problem but for legacy commits keeping the old cvs around would 
be good. Other projects had the problem of moving to git but not keeping 
that data around and causing issues.  The other thing I would point out 
in this discussion is to start figuring out history policies on branches 
e.t.c for merges,


cherry picking and bisect. Merges are the obvious one but bisect and 
cherry picking will depend on


the history choices over time as how useful they may become.

I've yet to see history choices discussed whether it be straight linear, 
branches and merge e.t.c.


but thought I will mention it again as I did at Cauldron briefly as 
this  will not be part of the merge


but important for future planning git migration or project strategies 
and should be discussed


or added to the wiki for git migration.

Cheers,

Nick

ToDos on Parallel GCC Wiki

[Nicholas Krause]

Greetings Richard,

Seems some of these things can either be closed or discussed here:

Add support to a multithread environment to Garbage Collector:

This may not matter as memory is in bulk at the beginning of passes. 
I've benchmarked


it and its less than 5% on the GCC test farm machines with make -j64.

Parallelize RTL part. This will improve our current results, as 
indicated in Results chapter:


struct function or function.c if I recall is using the most as one file 
at around 20-30% for


sure in building gcc with make -j64.

Make this GCC compile itself:

It does  now and I just tested it but I assuming he means with threads 
on and I'm not sure how


to enable them in the core Makefile for gcc or if just exporting CC/CXX 
is earlier with it


turned on.

I've also looked into the Linux Kernel work queues as those can scale 
much better than just


launching in async as we are doing currently. On the  testingside seems 
the Yocto Project is


working on testing upstream heads of projects like gcc. I've asked them 
to bring it up at the


usual IOT/Embedded Linux Conference meeting. This will also us to have 
access to not only


the gcc testsuite but access to build lots of real world software 
packages in a pretty automated


way as that was one concern that Giuliano brought up at the Cauldron 
this year.


Also if someone opens a more detailed ToDo with Bugs or something I 
would be able to help out more


or just CC on the issues or work that is ongoing as frankly seems I'm 
not been keeping good track,


Nick

Re: ToDos on Parallel GCC Wiki

[Nicholas Krause]

On 11/18/19 3:44 PM, Nicholas Krause wrote:


Greetings Richard,

Seems some of these things can either be closed or discussed here:

Add support to a multithread environment to Garbage Collector:

This may not matter as memory is in bulk at the beginning of passes. 
I've benchmarked


it and its less than 5% on the GCC test farm machines with make -j64.

Parallelize RTL part. This will improve our current results, as 
indicated in Results chapter:



struct function or function.c if I recall is using the most as one 
file at around 20-30% for


sure in building gcc with make -j64.

Make this GCC compile itself:

It does  now and I just tested it but I assuming he means with threads 
on and I'm not sure how



to enable them in the core Makefile for gcc or if just exporting 
CC/CXX is earlier with it



turned on.

I've also looked into the Linux Kernel work queues as those can scale 
much better than just



launching in async as we are doing currently. On the  testingside 
seems the Yocto Project is


working on testing upstream heads of projects like gcc. I've asked 
them to bring it up at the



usual IOT/Embedded Linux Conference meeting. This will also us to have 
access to not only


the gcc testsuite but access to build lots of real world software 
packages in a pretty automated



way as that was one concern that Giuliano brought up at the Cauldron 
this year.


Also if someone opens a more detailed ToDo with Bugs or something I 
would be able to help out more



or just CC on the issues or work that is ongoing as frankly seems I'm 
not been keeping good track,


Nick



Sorry Richard but seems but email client was formatting it incorrectly,

Seems some of these things can either be closed or discussed here:

Add support to a multithread environment to Garbage Collector:This may 
not matter as memory is in bulk at the beginning of passes.
I've benchmarkedit and its less than 5% on the GCC test farm machines 
with make -j64.Parallelize RTL part. This will improve our
current results, as indicated in Results chapter:struct function or 
function.c if I recall is using the most as one file at around 20-30%

forsure in building gcc with make -j64.

Make this GCC compile itself:

It does now and I just tested it but I assuming he means with threads on 
and I'm not sure how to enable them in the core  Makefile
for gcc or if just exporting CC/CXX is earlier with it turned on.I've 
also looked into the Linux Kernel work queues as those can scale
much better than just launching in async as we are doing currently. On 
the testing side seems the Yocto Project is working on testing

upstream heads of projects like gcc.

I've asked them to bring it up at the usual IOT/Embedded Linux 
Conference meeting. This will also us to have access to not only the
gcc testsuite but access to build lots of real world software packages 
in a pretty automated
way as that was one concern that Giuliano brought up at the Cauldron 
this year.


Also if someone opens a more detailed ToDo with Bugs or something I 
would be able to help out more
or just CC on the issues or work that is ongoing as frankly seems I'm 
not been keeping good track,


Nick

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/19/19 6:44 PM, Joseph Myers wrote:

On Tue, 19 Nov 2019, Segher Boessenkool wrote:


Most of the time after I type "git log" I type "/\<123456\>".  We need
to keep a way to easily map SVN revision ids to git commits, and
something a bit more elegant than the ugly git-svn footers would be nice.

Whatever reposurgeon's "write --legacy" yield seems appropriate for making
the SVN revision ids readily available in the commit messages.  I don't
think the summary line is a good place for that information.

I do think "Related to PR N (description)" or similar is a good
summary line to insert where the present summary line is just a ChangeLog
date/author line.

Sorry for pointing this out if it was not obvious but Related to PR N or
commit id in the message is fine. You would have to figure out whether the
git id is more important or the PR for each commit as normally only one
of these is used.

Normally in my experience git bisect or revert use ids directly but 
everything
else can just use the ported svn or PR from Bugzilla. It really depends 
but the
ids are more for if your dealing with the projects history itself rather 
than  just

a bug on the bugzilla.

That's just my opinion through so take it wait a grain of salt,
Nick

Re: GCC selftest improvements

[Nicholas Krause]

On 11/23/19 11:33 AM, Jeff Law wrote:

On 11/22/19 4:41 PM, Segher Boessenkool wrote:

On Fri, Nov 22, 2019 at 11:36:18PM +0100, Jakub Jelinek wrote:

On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote:

On Fri, Nov 22, 2019 at 09:02:05PM +, Andrew Dean wrote:

Many systems do not have a system compiler newer than this *four years
old* one.  GCC 4.8 is the first GCC version that supports all of
C++11, which is the only reason it would be even near acceptable to
require something this *new*.

Agreed.  Note we're even shipping new service packs for SLE12 which has that
"ancient" compiler version (OTOH there _is_ a fully supported GCC 9 available
for SLE12 as well).

So, if we want C++11 then fine.  But requiring GCC 9+ isn't going to fly.  IIRC
GCC 6 is first having -std=c++14 by default, but unless there's a compelling
reason to use C++14 in GCC I'd rather not do it at this point.

Removing all the workarounds in the tree we have for GCC 4.[12].x would of
course be nice.

But I have to update the testers that still use GCC 4.1.x as host compiler :P

Richard/Segher: Are we in agreement that we can move forward with updating to 
c++11 as the minimum version? I have made the simple change locally to modify 
the flag and verified that I got the exact same test results with/without the 
change. I can look into the work to add a configuration warning if the compiler 
doesn't support c++11, but wanted to make sure we are on the same page before 
doing so.

If GCC 4.8.5 works as bootstrap compiler, it is fine with me, and good
progress too.  (Which means 4.8.5 has to work for at least all primary
targets.)

What would be the advantage of bumping the requirement now as opposed to at
the start of next stage 1 though?  We should be fixing bugs now, not
introduce new features nor do code refactoring.

Oh, I meant for GCC 11, of course.  I thought we all agreed on that.

Yea, I don't see that stepping forward for gcc-10 really brings us
anything.  We're past stage1 and thus Andrew's work would naturally
target gcc-11.

So the advice I'd give Andrew is go ahead with using C++11 as needed.
However, also try to be sensible in terms of what features you use :-)

jeff

CCing myself to the conversation as the original idea contributor
for adding support for C++11.

Thanks,
Nick

Questions about where to find information on IPO state in GCC

[Nicholas Krause]

Greetings Richard,
After looking through the current work on multi-threading seems that we 
can scale
better with a workqueue strategy sharing and launching depending on how 
state is

shared between the GCC passes.

I'm not very familiar with all the details of how state is share in the 
GIMPLE,RTL or

SSA passes so I was wondering where to find information on this. The manual
only seems to mention the pass manager and its interactions with passes 
for running

them.

Thanks,
Nick

Possible Bugs in cgraphunit.c

[Nicholas Krause]

Greetings,
Seems that the extend_trucks return values are not returned when called 
in both,

cnode::assemble_thunks_and_aliases and cnode::create_wrapper. I'm not sure
if this is a set of edge case bugs or there was a reason for this. Seems 
not as its

checked in the third function caller in the file, cgraph_node::analyze.

Not sure if my assumptions are correct so I'm asking if there isn't 
another reason

for this as the code seems to have at least directly no reason for it,

Nick

Re: Possible Bugs in cgraphunit.c

[Nicholas Krause]

On 12/5/19 7:08 AM, Martin Liška wrote:

On 12/5/19 9:00 AM, Nicholas Krause wrote:

Greetings,
Seems that the extend_trucks return values are not returned when 
called in both,
cnode::assemble_thunks_and_aliases and cnode::create_wrapper. I'm not 
sure
if this is a set of edge case bugs or there was a reason for this. 
Seems not as its

checked in the third function caller in the file, cgraph_node::analyze.


Hello.

You are right that the return value of expand_thunk is not checked 
(except one place).

The code is quite old, so I guess it's not causing issues.

Martin

Indeed or the edge cases are almost never hit or not at all. So the 
question is should
we just change the function to return void as its always successful or 
fix up the callers?


Nick


Not sure if my assumptions are correct so I'm asking if there isn't 
another reason

for this as the code seems to have at least directly no reason for it,

Nick

Multi-Threading GCC Continuation

[Nicholas Krause]

Greetings Segher and Peter,

After looking through the code and thinking about it seems that the best 
way forward
is to rewrite most of the passes in GIMPLE or RTL to hook into a async 
work queue
framework to launch it if the state is not shared. This will scale much 
better than
the current version and be able to hook into newer passes if created 
that require it.


I'm not as familiar with the RTL backends on a expert level so your 
going to have to
answer some questions from me as I write out a very basic RFC for this 
using C++11
async and memory models in terms of passing state. Writing this sort of 
async code
unfortunately requires lots of experience with it as related to subtle 
details.


The first questions are:
1. What current heuristics do we have as it seems none for figuring out 
what state is shared
as it seems none? If I correct the first thing to do is discuss what 
bits/bitmasks we want

for figuring out shared state or other ways.
2. MD files seem to be a major source of shared state or reading them.  
Is it possible
to read from them async? Doesn't seem to be a problem but the current 
docs don't

mention it nor does it seem easy to do.
3. There are two ways to write this for RTL either one class for all the 
state or a core
class will each major part being a subclass like delayed branch 
scheduling e.t.c.Not sure

which is better so thought I would ask.

I'm going to start reading the register code more actively first in 
order to see what a

RFC would be there as its the most complex part according to Peter,

Nick

Status of C++11 support

[Nicholas Krause]

Greetings,

I was wondering what the current status of being able to use C++11 is 
without
the gcc project. Seems it will be much easier to implement  basic 
spinlocks with

the  C++11 memory model than without.

Thanks,
Nick

Re: Status of C++11 support

[Nicholas Krause]

On 12/9/19 3:16 AM, Dennis Luehring wrote:

Overview:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

I'm asking of what support exists in the gcc codebase itself not for other
projects using gcc.
Nick


Am 09.12.2019 um 04:17 schrieb Nicholas Krause:

Greetings,

I was wondering what the current status of being able to use C++11 is
without
the gcc project. Seems it will be much easier to implement basic
spinlocks with
the  C++11 memory model than without.

Thanks,
Nick

Re: Status of C++11 support

[Nicholas Krause]

On 12/9/19 1:09 PM, Andrew Haley wrote:

On 12/9/19 5:03 PM, Nicholas Krause wrote:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

I'm asking of what support exists in the gcc codebase itself not for other
projects using gcc.

That is what you got.



No its not  as its just talking about support for other projects using 
gcc. I'm asking

about the internal codebase itself which was written using C++03. That's my
point not support for other things using it but internal to gcc source 
code itself

which was in the works a few weeks ago.

Nick

Re: Status of C++11 support

[Nicholas Krause]

On 12/9/19 1:31 PM, Paul Smith wrote:

On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote:

On 12/9/19 5:03 PM, Nicholas Krause wrote:

https://gcc.gnu.org/projects/cxx-status.html#cxx11

I'm asking of what support exists in the gcc codebase itself not
for other projects using gcc.

That is what you got.

IIUC Nicholas is not asking what language features GCC _can compile_.
He's asking which language version the compiler itself is _written in_.

If he were to write a new GCC feature, can he write it in C++11?

I'm pretty sure the link above shows the former, not the latter.
Unless you're trying to imply, indirectly, that this is the language
GCC is written in as well as what it can compile.

Exactly as C++11 has a memory model which is useful for multi-threading
gcc alongside other things.

Sorry for the confusion,
Nick

Re: Multi-Threading GCC Continuation

[Nicholas Krause]

On 12/12/19 4:11 AM, Segher Boessenkool wrote:

Hi Nick,

On Sun, Dec 08, 2019 at 03:03:56PM -0500, Nicholas Krause wrote:

The first questions are:
1. What current heuristics do we have as it seems none for figuring out
what state is shared
as it seems none? If I correct the first thing to do is discuss what
bits/bitmasks we want
for figuring out shared state or other ways.

Shared between what and what?
Between the passes in gcc. If we can launch certain passes in  gcc on 
another
thread and join up to other passes that depend on the state used by a 
earlier

pass. For example if a loop pass does not touch outside a function in GIMPLE
or RTL we should launch it on another thread. Then join up to the next pass
that requires the state. Seems not all passes touch everything or only parts
of either GIMPLE or RTL so this may be worth considering. The question
was what internal compiler data can be currently use for finding when this
should be the case .  I don't see anything so figuring out how to detect 
this

is going to be part of the challenge.

I'm going to write up a wiki article on the GCC wiki explaining it 
better but

that's a very brief idea alongside some other ideas like figuring out if
dominator trees should or can be lockless or very close to in nature
for insertion/deletion.



2. MD files seem to be a major source of shared state or reading them.
Is it possible
to read from them async? Doesn't seem to be a problem but the current
docs don't
mention it nor does it seem easy to do.

MD files are not read *at all* by the compiler itself; they aren't
installed, even.  They are read by the gen* programs when the compiler
itself is built, to create the insn-*.c files and the like.


3. There are two ways to write this for RTL either one class for all the
state or a core
class will each major part being a subclass like delayed branch
scheduling e.t.c.Not sure
which is better so thought I would ask.

RTL as it is is pretty efficient.  Please keep it that way.  It also is
a dumb (and very "open") data structure, by design.  See how "XEXP" and
similar work.

That could be changed of course, for non-trivial cost, but what for?

I'm not talking about changing RTL itself it terms of its optimizations
but rewriting it for reading work queues in parallel on non shared
state between the current running pass and joining it back up
to the next pass requiring it.

For example why not run parts of the register allocation on separate
work queues if possible? I was asking Peter at Cauldron about the
register part and he seems to like doing something like this for
cost of allocating registers if I recall correctly.

Hopefully that explains it a little better,
Nick



Segher

Re: Multi-Threading GCC Continuation

[Nicholas Krause]

On 12/12/19 11:38 AM, Segher Boessenkool wrote:

On Thu, Dec 12, 2019 at 10:21:03AM -0500, Nicholas Krause wrote:

On 12/12/19 4:11 AM, Segher Boessenkool wrote:

On Sun, Dec 08, 2019 at 03:03:56PM -0500, Nicholas Krause wrote:

The first questions are:
1. What current heuristics do we have as it seems none for figuring out
what state is shared
as it seems none? If I correct the first thing to do is discuss what
bits/bitmasks we want
for figuring out shared state or other ways.

Shared between what and what?

Between the passes in gcc. If we can launch certain passes in  gcc on
another
thread and join up to other passes that depend on the state used by a
earlier
pass. For example if a loop pass does not touch outside a function in GIMPLE
or RTL we should launch it on another thread. Then join up to the next pass
that requires the state. Seems not all passes touch everything or only parts
of either GIMPLE or RTL so this may be worth considering. The question
was what internal compiler data can be currently use for finding when this
should be the case .  I don't see anything so figuring out how to detect
this
is going to be part of the challenge.

Every pass depends on the previous pass.  You cannot do later passes
before earlier ones (for the same function).

Each separate pass can do its own thing in whatever way it wants of
course.  Nothing else will access the insn stream while a pass is
running.

My idea was to use something similar to:
https://linux-kernel-labs.github.io/master/labs/deferred_work.html

It's under the section workqueues. It would allow us to defer
non shared work between the passes. For example if a loop
pass a has state that c depends on but not b, why not launch
it on a thread and join back up to c.

Here's it sorta draw out:

a-> has state that c depends on so launch a workqueue
    -> b no shared state with a so continue this in parallel
    ->  c waits for a to join back up with shared or dependency state

Of course if its the same function this would not work but the question
is and it seems to be a lot of passes touch only certain parts of
GIMPLE or RTL. Therefore doing in a workqueue would be ideal
if the state is not shared.

The real question is how to detect when to launch a workqueue based
on how shared state is passed to dependent passes on the earlier
passes transformations of GIMPLE or RTL.

3. There are two ways to write this for RTL either one class for all the
state or a core
class will each major part being a subclass like delayed branch
scheduling e.t.c.Not sure
which is better so thought I would ask.

RTL as it is is pretty efficient.  Please keep it that way.  It also is
a dumb (and very "open") data structure, by design.  See how "XEXP" and
similar work.

That could be changed of course, for non-trivial cost, but what for?

I'm not talking about changing RTL itself it terms of its optimizations
but rewriting it for reading work queues in parallel on non shared
state between the current running pass and joining it back up
to the next pass requiring it.

For example why not run parts of the register allocation on separate
work queues if possible? I was asking Peter at Cauldron about the
register part and he seems to like doing something like this for
cost of allocating registers if I recall correctly.

Hopefully that explains it a little better,

No, I still do not understand what you mean at all :-/

I'm going to invest a little further into how to do this on the register 
side

but hopefully my diagram above makes sense.

Nick
Sorry for the confusion,
Nick

Segher

Contributing to GCC Page Update?

[Nicholas Krause]

Greetings,
Not sure as I just checked, but is the  gcc webpage for contributing updated
for git or is it the same contributing guidelines but with git?

Thanks,
Nick

Re: access to Subversion links forbidden?

[Nicholas Krause via Gcc]

On 3/18/20 3:49 PM, Martin Sebor via Gcc wrote:

I've been getting Error 403 (Forbidden - You don't have permission
to access /viewcvs on this server) following the Subversion links
in Bugzilla for some time now (they worked for me before the switch
to Git, but I'm not sure if they also did before the recent hardware 
upgrade).


For example:
  https://gcc.gnu.org/viewcvs?rev=268827&root=gcc&view=rev
  https://gcc.gnu.org/viewcvs?rev=267096&root=gcc&view=rev
  https://gcc.gnu.org/viewcvs?rev=244881&root=gcc&view=rev

Are they supposed to work and if so, is anyone else having trouble with
them and is it a known problem that's already being worked on?

Thanks
Martin


Martin,
I've been having trouble with them as well for the last day or so. If I 
recall correctly they worked fine a few

weeks ago post Git so I've assuming its a current issue.

Nick

Possible Bug in make_more_copies

[Nicholas Krause via Gcc]

Greetings Segher,

I've not sure if I've misunderstanding something in the combine code but 
in make_more_copies

for combine.c this seems very odd:
if (!(REG_P (dest) && !HARD_REGISTER_P (dest)))
    continue;

    rtx src = SET_SRC (set);
    if (!(REG_P (src) && HARD_REGISTER_P (src)))
        continue;

Is there any good reason we are assuming the destination can't both be a 
hard register or a regular code here?

If were making pseudo register copies wouldn't it be:
  rtx dest = SET_DEST (dest);
    if ((REG_P (dest) && HARD_REGISTER_P (dest)))
        continue;

I'm assuming you have good reason for doing both hard and standard 
registers checking in this function but

it looks really odd to me for checking both hard and regular registers here,

Nick