Re: GCC selftest improvements
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
gcc-9-20191123 is now available
Snapshot gcc-9-20191123 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20191123/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9-branch revision 278650 You'll find: gcc-9-20191123.tar.xzComplete GCC SHA256=94ccde12e289e5b56f1669e544c084df76114cf44bcbe998756b8dd5d18e61f3 SHA1=d29251368c4b1d1b1b413270404d4f76801abcd1 Diffs from 9-20191116 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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
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
Re: Do we need to do a loop invariant motion after loop interchange ?
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.
Thanks,
bin
>
> Thanks,
> bin
> >
> > Richard.
linterchange-invariant-dataref-motion.patch
Description: Binary data
