Re: Questions about points-to analysis in gcc
On Fri, Oct 25, 2019 at 1:09 AM Gary Oblock wrote:
>
> I'm wondering if the code in tree-ssa-structalias.c can be invoked in
> a whole program mode? There are some comments in there about
> it not playing well with WHOPR and WPA (not that I intend to use
> that way.) Ironically, in the literature on points-to analysis this
> algorithm
> was only originally intended to be run on whole programs.
There's separate entries into the analysis for whole-program (ipa_pta_execute)
and single-function operation (compute_may_aliases) using the same
underlying constraint solver (but obviously slightly different
constraint setup).
Since constraint generation needs access to function bodies the whole-program
PTA analysis is currently not performed at WPA stage but for individual
LTRANS units, so it doesn't get to see the whole program after all (unless the
whole program fits into a single LTRANS unit or you use
-flto-partition={one,none}).
> By the way, how are the users of the points-to sets actually supposed
> to access and use them?
Generally points-to solutions are queried from the may-alias oracle but there's
the pt_solution_* API in tree-ssa-alias.h where the actual solutions have to
be get via SSA_NAME_PTR_INFO (so points-to solutions are only available
for SSA name pointers, not memory).
Richard.
>
> Thanks,
>
> Gary
>
Code bloat due to silly IRA cost model?
Hi,
I am trying to track down a code bloat issue and am stuck becauce I do
not understand IRA's cose model.
The test case is as simple as it gets:
float func (float);
float call (float f)
{
return func (f);
}
IRA dump shows the following insns:
(insn 14 4 2 2 (set (reg:SF 44)
(reg:SF 22 r22 [ f ])) "bloat.c":4:1 85 {*movsf}
(expr_list:REG_DEAD (reg:SF 22 r22 [ f ])
(nil)))
(insn 2 14 3 2 (set (reg/v:SF 43 [ f ])
(reg:SF 44)) "bloat.c":4:1 85 {*movsf}
(expr_list:REG_DEAD (reg:SF 44)
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SF 22 r22)
(reg/v:SF 43 [ f ])) "bloat.c":5:12 85 {*movsf}
(expr_list:REG_DEAD (reg/v:SF 43 [ f ])
(nil)))
(call_insn/j 7 6 8 2 (parallel [
#14 sets pseudo 44 from arg register R22.
#2 moves it to pseudo 43
#6 moves it to R22 as it prepares for call_insn #7.
There are 2 allocnos and cost:
Pass 0 for finding pseudo/allocno costs
a1 (r44,l0) best NO_REGS, allocno NO_REGS
a0 (r43,l0) best NO_REGS, allocno NO_REGS
a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
which is quite odd because MEM is way more expensive here than any REG.
Okay, so let's boost the MEM cost (TARGET_MEMORY_MOVE_COST) by a factor
of 100:
a1 (r44,l0) best NO_REGS, allocno NO_REGS
a0 (r43,l0) best NO_REGS, allocno NO_REGS
a0(r43,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000
a1(r44,l0) costs: ADDW_REGS:320 SIMPLE_LD_REGS:320
LD_REGS:320 NO_LD_REGS:320 GENERAL_REGS:320 MEM:801000
What??? The REG costs are 100 times higher, and stille higher that the
MEM costs. What the heck is going on?
Setting TARGET_REGISTER_MOVE_COST and also TARGET_MEMORY_MOVE_COST to 0
yiels:
a0(r43,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
GENERAL_REGS:0 MEM:0
a1(r44,l0) costs: ADDW_REGS:0 SIMPLE_LD_REGS:0 LD_REGS:0 NO_LD_REGS:0
GENERAL_REGS:0 MEM:0
as expected, i.e. there is no other hidden source of costs considered by
IRA. And even TARGET_REGISTER_MOVE_COST = 0 and
TARGET_MEMORY_MOVE_COST = original gives:
a0(r43,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
a1(r44,l0) costs: ADDW_REGS:32000 SIMPLE_LD_REGS:32000 LD_REGS:32000
NO_LD_REGS:32000 GENERAL_REGS:32000 MEM:9000
How the heck do I tell ira-costs that registers are way cheaper than MEM?
Johann
p.s.
test case compiled with
$ avr-gcc bloat.c -S -Os -dp -da -fsplit-wide-types-early -v
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-10 --disable-shared --disable-nls
--with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld
--enable-checking=release --enable-languages=c,c++ --disable-gcov
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191021 (experimental) (GCC)
Re: Proposal for the transition timetable for the move to GIT
On 19/09/2019 18:04, Paul Koning wrote: On Sep 17, 2019, at 8:02 AM, Richard Earnshaw (lists) wrote: ... So in summary my proposed timetable would be: Monday 16th December 2019 - cut off date for picking which git conversion to use Tuesday 31st December 2019 - SVN repo becomes read-only at end of stage 3. Thursday 2nd January 2020 - (ie read-only + 2 days) new git repo comes on line for live commits. That sounds ok but it feels incomplete; there are additional steps and dates needed leading up to the 16th December decision point. I would suggest: 1 December 2019: final version of each proposed conversion tool is available, trial conversion repository of the full GCC SVN repository is posted for public examination. That allows 2 weeks for the different tools and their output to get the scrutiny needed for the picking decision to be made. 2 weeks may be more than needed (or possibly, less), but in any case I think this piece needs to be called out. I don't think I want to start setting more hard deadlines. I'll simply say, the decision will be made on that date, based on the evidence we have. It's up to the proponents of the various conversion alternatives to be able to demonstrate before that time that their conversion meets the required criteria. I'm not interested in reviewing the tools used, per se. I am interested in ensuring that the conversions produced by them meet our requirements. Of course, if a sample conversion is only delivered the day before the deadline, we may have to decide that that doesn't leave us enough time to review it. But that might depend on what accompanying evidence is supplied along with such a conversion. R.
Re: Proposal for the transition timetable for the move to GIT
On 19/09/2019 15:42, Damian Rouson wrote: On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist wrote: One thing that's unclear to me is how should I actually make my stuff appear in the public repo? Say I want to work on some particular thing: This is essentially a git workflow question. A simple and useful workflow to consider is the GitHub Flow: https://guides.github.com/introduction/flow/. Others to consider are on the GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html and on Atlassian's Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html. Where will the GCC git repository be hosted? 1. git checkout -b pr1234-foo # A private branch based on latest trunk 2. Then when I'm happy, I send out a patch for review, either manually or with git format-patch + send-email. Will GCC allow workflows other than emailing patches? It could make contributing more inviting to new developers. A large community of developers has grown up around the above workflows and are used to using the related tools. I realize emailing patches probably seems simple to GCC developers, but that practice is one of the main reasons I haven't contributed code to GCC even though I have supported GCC development financially and I frequently interact with GCC developers. My problems with email have been many. I have often forgotten to set my emails to plain text so my emails to GCC lists bounce and I have to resend them (often hours later if I didn't see the bounce right away). When I receive patches from GCC developers, I get frustrated with determining what -p argument to pass when applying the patch. I'm equally daunted with the process of searching through emails to find related discussions rather than having all the dialogue about a pull request (which contains the same information as a patch) in one place. And with plain-text emails as the medium, I really miss the ability to format dialogues with Markdown, including inserting hyperlinks but also to tie comments to specific lines of code in a browser interface to the pull request, etc. 3. Patch goes through a few revisions, and is approved. 4. Now what? 4a) Do I merge my private branch to master (err, trunk?), then commit and push? It's safer to first merge master into your branch and then retest with all the new commits that have hit master since you branched. If you test right after merging and find no problems (and no new commits hit master while you're testing), then the head of your branch will reflect the state master will reach when you merge into master so you know it's safe to do so. 4b) Or do I first rebase my branch on top of the latest master, to produce a slightly less branchy history? A lot of people find rebasing to be overly complicated and error-prone (with the exception of interactive rebasing for the purpose of squashing commits that haven't been pushed to the remote repository). The above merging steps are easier at the expense of having merge commits in the history, which I think is good to better document the branching history. 4c) Or do I (manually?) apply my patch on master, to create a linear history? See above. I recommend "git merge" over manually applying patches. 4d) Something else entirely? A lot of the testing can be automated. For example, on GitHub, git hooks can be set up to ensure that if a branch has an open pull request against master (or other designated branches), tests run for that branch every time a new commit is pushed to it. Damian There will be NO changes to the basic workflow at the time of the transition, other than those that are strictly required by using git instead of SVN (ie you now have to type "git clone" rather than "svn checkout" and, for committers, "git push" rather than "svn checkin"). This is not to suggest that at some later date the workflows cannot change, but at this point in time the only change will be the underlying storage mechanism for the master repository. As Segher said, NO SCOPE CREEP. R.
Re: Proposal for the transition timetable for the move to GIT
On 10/25/19 8:10 AM, Richard Earnshaw (lists) wrote: > On 19/09/2019 15:42, Damian Rouson wrote: >> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist >> >> wrote: >> >>> >>> One thing that's unclear to me is how should I actually make my stuff >>> appear in the public repo? Say I want to work on some particular >>> thing: >>> >> >> This is essentially a git workflow question. A simple and useful >> workflow >> to consider is the >> GitHub Flow: https://guides.github.com/introduction/flow/. Others to >> consider are on the >> GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html >> and >> on Atlassian's >> Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html. >> Where >> will the GCC >> git repository be hosted? >> >> >>> 1. git checkout -b pr1234-foo # A private branch based on latest trunk >>> 2. Then when I'm happy, I send out a patch for review, either manually >>> or with git format-patch + send-email. >>> >> >> Will GCC allow workflows other than emailing patches? It could make >> contributing more >> inviting to new developers. A large community of developers has >> grown up >> around the >> above workflows and are used to using the related tools. I realize >> emailing patches >> probably seems simple to GCC developers, but that practice is one of the >> main reasons I >> haven't contributed code to GCC even though I have supported GCC >> development financially >> and I frequently interact with GCC developers. My problems with email >> have >> been many. >> I have often forgotten to set my emails to plain text so my emails to GCC >> lists bounce and >> I have to resend them (often hours later if I didn't see the bounce right >> away). When I >> receive patches from GCC developers, I get frustrated with determining >> what >> -p argument >> to pass when applying the patch. I'm equally daunted with the process of >> searching through >> emails to find related discussions rather than having all the dialogue >> about a pull request >> (which contains the same information as a patch) in one place. And with >> plain-text emails >> as the medium, I really miss the ability to format dialogues with >> Markdown, >> including inserting >> hyperlinks but also to tie comments to specific lines of code in a >> browser >> interface to the >> pull request, etc. >> >> 3. Patch goes through a few revisions, and is approved. >>> 4. Now what? >>> 4a) Do I merge my private branch to master (err, trunk?), then commit >>> and >>> push? >>> >> >> It's safer to first merge master into your branch and then retest with >> all >> the new commits >> that have hit master since you branched. If you test right after merging >> and find no >> problems (and no new commits hit master while you're testing), then the >> head of your >> branch will reflect the state master will reach when you merge into >> master >> so you know >> it's safe to do so. >> >> >>> 4b) Or do I first rebase my branch on top of the latest master, to >>> produce a slightly less branchy history? >>> >> >> A lot of people find rebasing to be overly complicated and error-prone >> (with the exception >> of interactive rebasing for the purpose of squashing commits that haven't >> been pushed to >> the remote repository). The above merging steps are easier at the >> expense >> of having >> merge commits in the history, which I think is good to better document >> the >> branching >> history. >> >> >>> 4c) Or do I (manually?) apply my patch on master, to create a linear >>> history? >> >> >> See above. I recommend "git merge" over manually applying patches. >> >> >>> 4d) Something else entirely? >>> >> >> A lot of the testing can be automated. For example, on GitHub, git hooks >> can be set up >> to ensure that if a branch has an open pull request against master (or >> other designated >> branches), tests run for that branch every time a new commit is pushed to >> it. >> >> Damian >> > > There will be NO changes to the basic workflow at the time of the > transition, other than those that are strictly required by using git > instead of SVN (ie you now have to type "git clone" rather than "svn > checkout" and, for committers, "git push" rather than "svn checkin"). > > This is not to suggest that at some later date the workflows cannot > change, but at this point in time the only change will be the underlying > storage mechanism for the master repository. As Segher said, NO SCOPE > CREEP. Agreed. Let's deal with the conversion and only the conversion. Any discussion about changing the workflows should be deferred until after the conversion is done. jeff
RE: GCC selftest improvements
> From: David Malcolm
> Sent: Thursday, October 24, 2019 11:18 PM
> On Thu, 2019-10-24 at 20:50 +, Andrew Dean via gcc wrote:
> Thanks for your email, it looks interesting. Is your code somewhere we can
> see
> it?
It can be -- what is the preferred way to share the code? Though to be honest I
can summarize the changes pretty quickly:
1. Add catch.hpp (the single include header from the Catch2 project) and a
small wrapper header around catch.hpp that temporarily fixes up some macros
that GCC defines to replace c library functions and does nothing if !CHECKING_P
2. Modify test methods like so:
- void test_this_thing ()
+ TEST_CASE("test this thing")
And
- ASSERT_EQ (a, b);
+ REQUIRE (a == b);
3. Invoke the Catch2 test runner during selftest like:
Catch::Session ().run ();
4. Remove the manual invocations of the test methods, as the TEST_CASE macro
takes care of self-registration.
> I think the consensus during review was that I was over-engineering things,
> and
> that each iteration from v1 to v8 made the code simpler and involved less C++
> "magic", closer to C. Whether that's still the consensus I don't know.
> Different
> people within the GCC dev community have different comfort levels with C++,
> and my initial version (using
> gtest) was probably too "magic" for some. Maybe people here are more
> comfortable with C++ now?
Here's hoping! Looks like you had a very similar starting point as what I
suggested here.
> GCC has some rather unique requirements, in that we support a great many
> build configurations, some of which are rather primitive - for example,
> requiring just C++98 with exceptions disabled, in that we want to be able to
> be
> bootstrappable on relatively "ancient" configurations.
> IIRC auto-registration of tests requires that the build configuration have a
> sufficiently sane implementation of C++ - having globals with non-trivial
> ctors
> tends to be problematic when dealing with early implementations of C++.
Is C++98 the limit of what we can use in GCC? If so, that immediately
eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
> Personally I don't find the manual registration of tests to be a pain, but it
> would
> be nice to have more readable errors on failures. There's probably a case for
> more verbose test output. (generally I immediately just do "make
> selftest-gdb"
> on failures; the issue is if it suddenly starts failing on a build I don't
> have access
> to)
I didn't know about selftest-gdb. That will come in handy. My ideal programming
style, is to write a new test, watch it fail for the expected reason, then
write the production code to make it pass. Having to attach a debugger to
validate/investiigate failures slows down the process, as does having to write
the additional code to invoke the new test methods, if only by a little bit.
> I suspect that exceptions would be a deal-breaker; does Catch2 support -fno-
> exceptions?
Yes, Catch2 supports -fno-exceptions, though not like GTest, which was built to
not use exceptions at all. Catch2 stops running tests at the first failure and
gives the output as shown in the original email.
> As for setup/teardown, I've been able to do that "manually" using RAII- style
> classes in test functions.
Yes, I have added some RAII classes to assist in testing as well. I just think
it will be even better if it were easier to do.
gcc-8-20191025 is now available
Snapshot gcc-8-20191025 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20191025/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 277462 You'll find: gcc-8-20191025.tar.xzComplete GCC SHA256=a593a993a3ef9ccbbb6d267661a198040e9546d80615fbb7929178f41cab4dbe SHA1=0efd68421d26e52708ba01f05e91a24b2b878041 Diffs from 8-20191018 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: GCC selftest improvements
[Andrew] | > GCC has some rather unique requirements, in that we support a great many | > build configurations, some of which are rather primitive - for example, | > requiring just C++98 with exceptions disabled, in that we want to be able to | be | > bootstrappable on relatively "ancient" configurations. | > IIRC auto-registration of tests requires that the build configuration have a | > sufficiently sane implementation of C++ - having globals with non-trivial | ctors | > tends to be problematic when dealing with early implementations of C++. | | Is C++98 the limit of what we can use in GCC? If so, that immediately | eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11) C++98 was what Diego, Lawrence, Benjamin, Ian, and myself could agreed to back in 2011-2012 when C++11 got just out as a C++ standard, so we couldn't pick C++11 as we didn't have enough G++ out there to count on. I would expect the situation to have drastically changed - with very handy and popular features such as 'constexpr' (especially with the C++14 relaxation), lambdas and range-for. Jason, Jonathan - is the situation on the terrain really that dire that C++11 (or C++14) isn't at all available for platforms that GCC is bootstrapped from? -- Gaby
