Re: missed PTA optimization?
On Tue, Feb 11, 2020 at 10:27 PM Uecker, Martin
wrote:
>
> Am Dienstag, den 11.02.2020, 21:43 +0100 schrieb Richard Biener:
> > On February 11, 2020 9:32:14 PM GMT+01:00, "Uecker, Martin"
> >
> > wrote:
> > >
> > > In the following example, it seems
> > > that 'bar' could be optimized to
> > > return '1' and every else could be
> > > optimized away. Or am I missing
> > > something?
> >
> > p might be still NULL when bar is called.
> >
> > > Do I need to add
> > > some specific compiler flags?
> >
> > -fipa-pta
>
> This does not appear to change anything. Also
> if I initialize p to the address of 'a', this
> changes nothing.
>
> For the second function, I get:
>
> p = { ESCAPED NONLOCAL }
You have to look at the 0.86i.pta2 dump, there I see
p = { a } same as p.0_1
p.0_1 = { a }
if you then for example look at 100t.alias with -alias dumped you see this
local PTA pass is skipped:
Not re-computing points-to information because IPA points-to
information is available.
and we have
p.0_1, points-to NULL, points-to vars: { D.1929 } (nonlocal)
bar ()
{
int * p.0_1;
int _3;
[local count: 1073741824]:
# PT = null { D.1929 } (nonlocal)
p.0_1 = p;
_3 = *p.0_1;
return _3;
correctly saying that p.0_1 points to NULL or D.1929 (that's a). But
as I said nothing makes use
of this but a conservative correct "optimization" would be to transform this to
if (p.0_1)
_3 = a;
else
_3 = *p.0_1;
and eventually elide the conditional with some extra compile-flag
since it changes observable
behavior with POSIX in mind.
A slight complication is that the points-to sets contain DECL_UIDs but
there's no back-mapping
of UID to decl. The IPA points-to pass could do the transform since
it still knows the actual decl
though. Still I guess that the transform isn't a win in general so
handling it in value-numbering
would be better (but then the UID to decl issue arises).
> > But we simply do not implement turning pointer dereference into direct
> > accesses when points to
> > says it would be possible. And yes, the NULL case can probably be ignored
> > (though we generally
> > support catching NULL dereferences with signal handlers), or at least
> > speculated away with a well
> > predicted branch.
> >
> > Any situation where doing the above is profitable?
>
> No, just trying to understand what is happening.
> (clang does this optimization).
>
> Best,
> Martin
>
> > >
> > >
> > > static int a = 1;
> > > static int *p;
> > >
> > > extern
> > > void foo(void)
> > > {
> > > p = &a;
> > > }
> > >
> > > extern
> > > int bar(void)
> > > {
> > > return *p;
> > > }
> > >
> > >
> > > thank you,
> > > Martin
> >
> >
[VERY URGENT] GNU ideas for GSOC 2020
Hi people! Once again, we are applying as a mentoring organization for GSOC 2020. At this point, we need to populate our ideas page with projects [1]. This should be done before this Thursday (yes tomorrow). So, if you want your GNU package to participate in GSOC, please send us your ideas to summer-of-c...@gnu.org ASAP! For each project idea, we need: - Name of the GNU program. Example: GNU poke. - Summary of the project/idea. Example: DWARF to Poke translator - Little paragraph explaining the project/idea. - Skills required. Example: Good knowledge of DWARF, C programming. - Contact address for interested students. Example: poke-de...@gnu.org If you have an external page where you are documenting your ideas, then please send us the URL so we can list it in the main page. Sorry for the late notice! And thanks! :) PS: Note this list of projects don't have to be exhaustive, and we can always expand it afterwards, but they are needed for Google to consider whether accepting the org. [1] https://www.gnu.org/software/soc-projects/ideas.html
Re: [VERY URGENT] GNU ideas for GSOC 2020
Hi again. David points me out that GCC applied on its own as a mentoring organization for GSOC 2020, so please disregard the previous email, which applies to GNU projects _not_ applying on their own. Sorry for the noise, and good luck with the application! :) Salud! /me whips himself for hasty posting
Re: GCC GSoC 2020: Call for mentors and project ideas
On Thu, 2020-02-06 at 20:58 -0500, David Malcolm wrote: > On Mon, 2020-01-27 at 16:30 +0100, Martin Liška wrote: > > On 1/15/20 11: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 > > > > @David would you be interested in a analyzer topics? Seems to me > > ideal for newcomers to come up with a static analyzer check? > > I'm not quite sure what the appropriate size of a project would be, > but > I'd be happy to mentor a student. Some ideas I had for analyzer > topics: > > * Generalize double-free checker to attribute-marking of > acquire/release API entrypoints so that the user can mark the > entrypoints and get a checker for that API "for free". > > * Checking of the POSIX file-descriptor APIs (int rather than FILE > *), > or some other POSIX API that we're not yet checking. > > * Maybe add plugin support, and write a plugin to add a project > specific-checker for a project of interest to the student (Linux > kernel?) > > * C++ support (new/delete checking, exceptions, etc) > > Thoughts? > Dave I've taken the liberty of adding the above idea to the list of "Selected Project Ideas for 2020" on https://gcc.gnu.org/wiki/SummerOfCode with me as mentor. Dave
Re: GCC GSoC 2020: Call for mentors and project ideas
Dear GCC Team, A bit of a procedural question. Do applications/projects for glibc apply here to GCC? There are a few core functions I would like to add to the library, that I think would be beneficial. Would a proposal for that be welcome to GCC, or is it headed by a different organization? Sincerely, JeanHeyd Meneide On Wed, Feb 12, 2020 at 11:55 PM David Malcolm wrote: > On Thu, 2020-02-06 at 20:58 -0500, David Malcolm wrote: > > On Mon, 2020-01-27 at 16:30 +0100, Martin Liška wrote: > > > On 1/15/20 11: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 > > > > > > @David would you be interested in a analyzer topics? Seems to me > > > ideal for newcomers to come up with a static analyzer check? > > > > I'm not quite sure what the appropriate size of a project would be, > > but > > I'd be happy to mentor a student. Some ideas I had for analyzer > > topics: > > > > * Generalize double-free checker to attribute-marking of > > acquire/release API entrypoints so that the user can mark the > > entrypoints and get a checker for that API "for free". > > > > * Checking of the POSIX file-descriptor APIs (int rather than FILE > > *), > > or some other POSIX API that we're not yet checking. > > > > * Maybe add plugin support, and write a plugin to add a project > > specific-checker for a project of interest to the student (Linux > > kernel?) > > > > * C++ support (new/delete checking, exceptions, etc) > > > > Thoughts? > > Dave > > I've taken the liberty of adding the above idea to the list of > "Selected Project Ideas for 2020" on > https://gcc.gnu.org/wiki/SummerOfCode > with me as mentor. > > Dave > >
Re: GCC GSoC 2020: Call for mentors and project ideas
On Thu, 13 Feb 2020, JeanHeyd Meneide wrote: > Dear GCC Team, > > A bit of a procedural question. Do applications/projects for glibc > apply here to GCC? There are a few core functions I would like to add to > the library, that I think would be beneficial. Would a proposal for that be > welcome to GCC, or is it headed by a different organization? glibc ideas can be included under GNU, which has applied separately from GCC. https://gcc.gnu.org/ml/gcc/2020-02/msg00121.html -- Joseph S. Myers jos...@codesourcery.com
RE: [EXTERNAL] Re: GCC selftest improvements
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 c++11.patch Description: c++11.patch
Re: [EXTERNAL] Re: GCC selftest improvements
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
Re: [EXTERNAL] Re: GCC selftest improvements
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: Do we need to do a loop invariant motion after loop interchange ?
Hi,
On 2019/11/25 5:55 PM, Bin.Cheng wrote:
On Mon, Nov 25, 2019 at 5:29 PM Li Jia He wrote:
On 2019/11/24 2:26 PM, Bin.Cheng wrote:
On Fri, Nov 22, 2019 at 3:23 PM Bin.Cheng wrote:
On Fri, Nov 22, 2019 at 3:19 PM Richard Biener
wrote:
On November 22, 2019 6:51:38 AM GMT+01:00, Li Jia He
wrote:
On 2019/11/21 8:10 PM, Richard Biener wrote:
On Thu, Nov 21, 2019 at 10:22 AM Li Jia He
wrote:
Hi,
I found for the follow code:
#define N 256
int a[N][N][N], b[N][N][N];
int d[N][N], c[N][N];
void __attribute__((noinline))
double_reduc (int n)
{
for (int k = 0; k < n; k++)
{
for (int l = 0; l < n; l++)
{
c[k][l] = 0;
for (int m = 0; m < n; m++)
c[k][l] += a[k][m][l] * d[k][m] + b[k][m][l] * d[k][m];
}
}
}
I dumped the file after loop interchange and got the following
information:
[local count: 118111600]:
# m_46 = PHI <0(7), m_45(11)>
# ivtmp_44 = PHI <_42(7), ivtmp_43(11)>
_39 = _49 + 1;
[local count: 955630224]:
# l_48 = PHI <0(3), l_47(12)>
# ivtmp_41 = PHI <_39(3), ivtmp_40(12)>
c_I_I_lsm.5_18 = c[k_28][l_48];
c_I_I_lsm.5_53 = m_46 != 0 ? c_I_I_lsm.5_18 : 0;
_2 = a[k_28][m_46][l_48];
_3 = d[k_28][m_46];
_4 = _2 * _3;
_5 = b[k_28][m_46][l_48];
_6 = _3 * _5;
_7 = _4 + _6;
_8 = _7 + c_I_I_lsm.5_53;
c[k_28][l_48] = _8;
l_47 = l_48 + 1;
ivtmp_40 = ivtmp_41 - 1;
if (ivtmp_40 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
we can see '_3 = d[k_28][m_46];' is a loop invariant.
Do we need to add a loop invariant motion pass after the loop
interchange?
There is one at the end of the loop pipeline.
Hi,
The one at the end of the loop pipeline may miss some optimization
opportunities. If we vectorize the above code (a.c.158t.vect), we
can get information similar to the following:
bb 3:
# m_46 = PHI <0(7), m_45(11)> // loop m, outer loop
if (_59 <= 2)
goto bb 20;
else
goto bb 15;
bb 15:
_89 = d[k_28][m_46];
vect_cst__90 = {_89, _89, _89, _89};
bb 4:
# l_48 = PHI // loop l, inner loop
vect__6.23_100 = vect_cst__99 * vect__5.22_98;
if (ivtmp_110 < bnd.8_1)
goto bb 12;
else
goto bb 17;
bb 20:
bb 18:
_27 = d[k_28][m_46];
if (ivtmp_12 != 0)
goto bb 19;
else
goto bb 21;
Vectorization will do some conversions in this case. We can see
‘ _89 = d[k_28][m_46];’ and ‘_27 = d[k_28][m_46];’ are loop invariant
relative to loop l. We can move ‘d[k_28][m_46]’ to the front of
‘if (_59 <= 2)’ to get rid of loading data from memory in both
branches.
The one at at the end of the loop pipeline can't handle this situation.
If we move d[k_28][m_46] from loop l to loop m before doing
vectorization, we can get rid of this situation.
But we can't run every pass after every other. With multiple passes having
ordering issues is inevitable.
Now - interchange could trigger a region based invariant motion just for the
nest it interchanged. But that doesn't exist right now.
With data reference/dependence information in the pass, I think it
could be quite straightforward. Didn't realize that we need it
before.
FYI, attachment is a simple fix in loop interchange for the reported
issue. It's untested, neither for GCC10.
Hi,
Thank you for providing a patch so quickly. I did some tests for this
patch.
I found it will cause some test cases failed such as
testsuite/gfortran.dg/vect/pr81303.f.
My bad. It fails because the patch only hoists memory reference, but
not variables used by it.
I have made some improvements on this basis, and will mention the variables
needed for memroy reference to the preheader. The specific ideas are as
follows: We start from the offset of the memory reference, then search the
definition of the offset. From the use of the variable to search the
definition of the variable until all the definitions of the variable are
outside of the loop or encounter a situation that cannot be handled.
:
# l_32 = PHI <1(12), l_54(21)> // loop l
_36 = (integer(kind=8)) m_55;
_37 = _36 * stride.88_111;
_38 = _35 + _37;
_39 = _26 + _38;
_40 = (*a_137(D))[_39];
Suppose _40 is the memroy reference that needs to be processed. The
variables
searched here are _39, _26, _38, _35, _37, _36. And move them to the
preheader
respectively. The order is _36, _37, _35, _38, _39 (_26 not moved
because its
definition is already outside the loop).
In addition, we may need to deal with the problem of memroy reference being
accessed multiple times in a loop. The following is an example:
:
# ivtmp_58 = PHI <_60(9), ivtmp_59(10)>
_12 = i_52 + -1;
_8 = (integer(kind=8)) _12;
_4 = MEM[(integer(kind=4)[32] *)_18][_8];
_16 = _4 + 1;
MEM[(integer(kind=4)[32] *)_18][_8] = _16;
ivtmp_59 = ivtmp_58 - 1;
if (ivtmp_59 == 0)
goto ; [3.12%]
else
