Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level
Hi! On Tue, Mar 03, 2020 at 10:25:32PM +0100, Jan Hubicka wrote: > I think this is bit stronger to what llvm does currently which relies on > outlining SESE regions earlier rather than going through the pain of > implementing support for partitioning. OTOH outlining can result in improved code, too (it will naturally keep all "cold" variables in the cold outlined function, because of SESE). > 3) function partitioning is enabled only for x86. I never had time to > get it working on other targets and no-one picked up this task What makes this not completely generic in the first place? > 8) Most of non-x86 backends do not implement very well the hot/cold > code models and instruction choice. I'm not sure what this means, could you expand? > 9) Shrink-wrapping and register allocation is not always able to move > spilling to code paths but this is generally very hard problem to > track. Separate shrink-wrapping should handle this quite well. But, currently shrink-wrapping does not move existing code very much, which could improve this further (doing some kind of rematerialisation, essentially). Segher
Re: GCC 8.5 Status Report (2020-03-04)
On Wed, Mar 04, 2020 at 01:45:25PM +, Jonathan Wakely wrote: > On Wed, 4 Mar 2020 at 13:02, Jakub Jelinek wrote: > > The test says: > > // nl_NL chosen because it has no thousands separator (at this time). > > locale loc_it = locale(ISO_8859(15,nl_NL)); > > so no wonder that it FAILs if nl_NL now has thousands separator. > > Drat. I thought we could rely on the Dutch to keep things simple, > apparently even they want to keep changing things ;-) It has been like this since forever; just the locale used to be wrong. Segher
How do I run SIMD Testcases on PPC64?
I tried the make command below:
make check RUNTESTFLAGS="*.exp=*simd*"
gcc.log did not have any output indicating that it ran
.../gcc/testsuite/gcc.dg/vect/vect-simd-2.c
At the top of that file is dejagnu directive:
/* { dg-require-effective-target vect_int } */
1. How do I check to see if vect_int is defined? I suspect it as the reason
the test isn't run.
2. Multiple other testcases in testsuite/gcc.dg/vect/ have this line at the top:
/* { dg-additional-options "-mavx" { target avx_runtime } } */
An example is vect-simd-16.c
2.1 Should not these testcases be in directory testsuite/gcc.target/i386/ ?
2.2 To run vect-simd-16.c on PPC64, is it enough to put a copy of the file
in testsuite/gcc.target/powerpc/ ? (After modifying target appropriately.)
Thanks.
Bert.
libgccjit maintenance status
Hi all, I'd like to ask about the maintenance status of libgccjit. Personally (in my spare time) I'd like to contribute more to it but I feel the development is a little stuck and patches don't get reviewed[1]. More widely speaking we have a feature branch under active development in emacs.git that relies on libgccjit therefore its maintenance status is a fundamental information to have. Alternatively what can I do to help speed up the review of these patches? Thanks and Regards Andrea [1] https://gcc.gnu.org/ml/jit/2020-q1/msg2.html https://gcc.gnu.org/ml/jit/2020-q1/msg1.html
GCC 9.3 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 9.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.3.0-RC-20200305/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.3.0-RC-20200305/ and shortly its mirrors. It has been generated from git commit r9-8351-ge50627ff8cd54c3983614b34727323b333b9374d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 9.3 on Thursday, March 12th.
GCC 9.3 Status Report (2020-03-05)
Status == The GCC 9 branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. Quality Data Priority # Change from last report --- --- P10 P2 226 - 17 P3 37 + 2 P4 168 - 1 P5 23 --- --- Total P1-P3 263 - 15 Total 454 - 16 Previous Report === https://gcc.gnu.org/ml/gcc/2020-02/msg00238.html
Re: How do I run SIMD Testcases on PPC64?
On Thu, Mar 05, 2020 at 05:04:16PM +, GT wrote: > I tried the make command below: > > make check RUNTESTFLAGS="*.exp=*simd*" I think you can't use wildcards in the name of the *.exp file. So, you need to know which *.exp it is and use make check RUNTESTFLAGS="dg.exp=*simd* vect.exp=*simd* gomp.exp=*simd*" etc. Note simd_clones tests are also in libgomp testsuite. Jakub
Re: libgccjit maintenance status
On Thu, 2020-03-05 at 19:40 +, Andrea Corallo wrote: > Hi all, > > I'd like to ask about the maintenance status of libgccjit. I'm the maintainer. GCC 10 is currently in stage 4 so making changes may require release-manager signoff. > Personally (in my spare time) I'd like to contribute more to it but I > feel the development is a little stuck and patches don't get > reviewed[1]. Sorry about that. I know I lost some email at the end of last year, and I've been very busy working on the static analyzer [2]. Please ping the list weekly if I'm not getting around to reviewing patches. > More widely speaking we have a feature branch under active > development in emacs.git that relies on libgccjit therefore its > maintenance status is a fundamental information to have. > > Alternatively what can I do to help speed up the review of these > patches? > > Thanks and Regards > > Andrea > > [1] https://gcc.gnu.org/ml/jit/2020-q1/msg2.html > https://gcc.gnu.org/ml/jit/2020-q1/msg1.html I'll take a look at these today. Sorry about the delay Dave [2] https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
Re: How do I run SIMD Testcases on PPC64?
On Thu, Mar 05, 2020 at 05:04:16PM +, GT wrote:
> At the top of that file is dejagnu directive:
> /* { dg-require-effective-target vect_int } */
>
> 1. How do I check to see if vect_int is defined? I suspect it as the reason
> the test isn't run.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/lib/target-supports.exp;h=ca3895c22690dc15b6c2beffb53ea6f39ad80b38;hb=HEAD#l3258
(It is always true for powerpc, since we no longer support the
linuxpaired target).
You can look in the generated gcc.log, and if what you are looking for
isn't there, you can pass --debug to runtest as well, and look in the
relevant dbg.log . But first look in target-supports.exp if it is
something trivial ;-)
> 2. Multiple other testcases in testsuite/gcc.dg/vect/ have this line at the
> top:
> /* { dg-additional-options "-mavx" { target avx_runtime } } */
> An example is vect-simd-16.c
>
> 2.1 Should not these testcases be in directory testsuite/gcc.target/i386/ ?
> 2.2 To run vect-simd-16.c on PPC64, is it enough to put a copy of the file
> in testsuite/gcc.target/powerpc/ ? (After modifying target appropriately.)
The test is run on all platforms. If avx_runtime is true, it will add
the -mavx option. This isn't relevant for powerpc; this line does
nothing for powerpc targets.
It certainly would be nice if generic tests did not often have target-
specific stuff in them. In this case, it could be hidden in vect.exp,
perhaps?
Segher
