Re: libmvec in gcc to have vector math in fortran
On Tue, Apr 17, 2018 at 3:54 PM, Szabolcs Nagy wrote:
> On 10/04/18 14:27, Richard Biener wrote:
>>
>> On April 10, 2018 3:06:55 PM GMT+02:00, Jakub Jelinek
>> wrote:
>>>
>>> On Tue, Apr 10, 2018 at 02:55:43PM +0200, Richard Biener wrote:
I wonder if it is possible for glibc to ship a "module" for fortran
>>>
>>> instead
containing the appropriate declarations and gfortran auto-include
>>>
>>> that
(if present).
>>>
>>>
>>> Then we'd run into module binary format changing every release, so hard
>>> for
>>> glibc to ship that.
>>>
>>> Another thing is how would we express it in the module,
>>> we could just use OpenMP syntax,
>>> interface
>>> function sin(x) bind(C,name="__builtin_sin") result(res)
>>> import
>>> !$omp declare simd notinbranch
>>> real(c_double) :: res
>>> real(c_double),value :: x
>>> end function
>>> end interface
>>> but we'd need to temporarily enable OpenMP while parsing that module.
>>> I see Fortran now supports already
>>> !GCC$ attributes stdcall, fastcall::test
>>> Could we support
>>> !GCC$ attributes simd
>>> and
>>> !GCC$ attributes simd('notinbranch')
>>> too?
>>
>>
>> Maybe we can also generate this module in a fixinlclude way?
>>
>
> ideally everything should work magically but i think
> it's good to have a big hammer solution that's easy
> to reason about.
>
> the gcc vectorizer should be testable independently
> of glibc, and users should be able to specify what
> can be vectorized.
>
> if this is via a per-frontend declaration syntax,
> then i see implementation and usability issues, while
> those are sorted out a single flag that requests every
> function known to gcc to be vectorized sounds to me a
> viable big hammer solution: easy to implement and
> enables users to start experimenting with simd math.
>
> (the implementation may use a preincluded fortran
> module internally, but i think it makes sense to
> have a single flag ui too)
OK, so we could add a -fveclibabi=openmp which means
implicitely annotating all math (or others we see fit) builtins
with openmp-simd.
But then the user has to provide a library with implementations.
Or we arrange for them to be emitted in each TU, somehow
weakly binding, if the target supports that, implementing the
desired ABI but using trivial implementations dispatching to
the scalar libm routines.
Richard.
Deprecation of powerpc*-*-*spe*
As has been discussed in the https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01227.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00810.html threads and in https://gcc.gnu.org/PR81084 the powerpc*-*-*spe* support which has been split into a separate backend hasn't been given enough maintainance and so is deprecated in GCC 8. It can still be built with --enable-obsolete. If the maintainers don't manage to remove the dead parts of the port and start actually maintaining it early in the GCC 9 stage1 development, the port will be removed.
Should CET be enabled by default in GCC8
Hello! Currently, CET is enabled by default for linux if target supports multi-byte NOPs and if assembler supports CET insn. Effectively, with newer binutils, CET support is an opt-out feature. I don't think this should be the case, and I propose to consider CET as an opt-in feature. Multi-byte NOPs have non-zero cost (at least they increase the binary). If someone wants to enable the feature, it can be done in less surprising way to --enable-cet during configure time. I'd like to hear the opinion of RMs, if CET should remain to be an opt-out feature by default? Uros.
Re: Should CET be enabled by default in GCC8
On Wed, 18 Apr 2018, Uros Bizjak wrote: > Hello! > > Currently, CET is enabled by default for linux if target supports > multi-byte NOPs and if assembler supports CET insn. Effectively, with > newer binutils, CET support is an opt-out feature. > > I don't think this should be the case, and I propose to consider CET > as an opt-in feature. Multi-byte NOPs have non-zero cost (at least > they increase the binary). If someone wants to enable the feature, it > can be done in less surprising way to --enable-cet during configure > time. > > I'd like to hear the opinion of RMs, if CET should remain to be an > opt-out feature by default? My personal opinion is that CET should be opt-in (I explicitely disable it for SUSE). I'm not sure if it doesn't go the way MPX did and given there's not even rumors when silicon will have an actual implementation nor whether the competition will (be allowed to) implement it it's too early to force it on everybody. Just my 2 cents - I can live with providing --disable-cet manually as well. I note that changes.html doesn't say anything about this new default or the way to disable it which IMHO needs fixing (in either case). Richard.
Re: Should CET be enabled by default in GCC8
On Wed, Apr 18, 2018 at 12:30:03PM +0200, Richard Biener wrote: > On Wed, 18 Apr 2018, Uros Bizjak wrote: > > > Hello! > > > > Currently, CET is enabled by default for linux if target supports > > multi-byte NOPs and if assembler supports CET insn. Effectively, with > > newer binutils, CET support is an opt-out feature. > > > > I don't think this should be the case, and I propose to consider CET > > as an opt-in feature. Multi-byte NOPs have non-zero cost (at least > > they increase the binary). If someone wants to enable the feature, it > > can be done in less surprising way to --enable-cet during configure > > time. > > > > I'd like to hear the opinion of RMs, if CET should remain to be an > > opt-out feature by default? > > My personal opinion is that CET should be opt-in (I explicitely > disable it for SUSE). I'm not sure if it doesn't go the way MPX I agree it should be opt-in, have said that in the past already. In Fedora it will not make a difference, as the whole distro is built with -mcet -fcf-protection on i?86/x86_64. Jakub
Re: Should CET be enabled by default in GCC8
On Wed, Apr 18, 2018 at 3:34 AM, Jakub Jelinek wrote: > On Wed, Apr 18, 2018 at 12:30:03PM +0200, Richard Biener wrote: >> On Wed, 18 Apr 2018, Uros Bizjak wrote: >> >> > Hello! >> > >> > Currently, CET is enabled by default for linux if target supports >> > multi-byte NOPs and if assembler supports CET insn. Effectively, with >> > newer binutils, CET support is an opt-out feature. >> > >> > I don't think this should be the case, and I propose to consider CET >> > as an opt-in feature. Multi-byte NOPs have non-zero cost (at least >> > they increase the binary). If someone wants to enable the feature, it >> > can be done in less surprising way to --enable-cet during configure >> > time. >> > >> > I'd like to hear the opinion of RMs, if CET should remain to be an >> > opt-out feature by default? >> >> My personal opinion is that CET should be opt-in (I explicitely >> disable it for SUSE). I'm not sure if it doesn't go the way MPX > > I agree it should be opt-in, have said that in the past already. > In Fedora it will not make a difference, as the whole distro is > built with -mcet -fcf-protection on i?86/x86_64. > I submitted a patch to add -mnop to enable multi-byte NOP code generation which can be used with -fcf-protection to implement indirect branch and return address tracking without -mcet: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00868.html -- H.J.
Re: Deprecation of powerpc*-*-*spe*
Hi Jakub! As has been discussed in the https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01227.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00810.html threads and in https://gcc.gnu.org/PR81084 the powerpc*-*-*spe* support which has been split into a separate backend hasn't been given enough maintainance and so is deprecated in GCC 8. I'm surprised that these topics are hardly ever discussed with downstream projects like Debian. I am maintaining powerpcspe in Debian and the port is very stable for us. There are people running the port on embedded PowerPC e500 systems like A-EON Tabor A1222 or the powerpc-based Turris router so killing off gcc support would mean that these people can no longer run an updated version of Debian on their machines. I also don't know why the port is considered to be broken. I haven't run the testsuite for binutils or gcc recently, true, but gcc-8 works just fine on powerpcspe and is actually the only current compiler we have since the powerpcspe support in LLVM is incomplete. Here's the build log of gcc-8 (20180402) built natively on PowerPC e500 just two weeks ago: https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=powerpcspe&ver=8-20180402-1&stamp=1522856967&raw=0 Is there anything in the powerpcspe port that is currently making life for the users or developers of other code harder? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
gcc-6-20180418 is now available
Snapshot gcc-6-20180418 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180418/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 259480 You'll find: gcc-6-20180418.tar.xzComplete GCC SHA256=d08953a76e535d5ef2552c4ce90d6952068d695bc6410216e551efba0bcd30a8 SHA1=13c673ee6b6662a15089d8aa3a1fea243ad17b28 Diffs from 6-20180411 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 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: How to get best AVX2 performance from gfortran?
Hi Matt, [timings] Intel AVX2: C_SW 1.4931 D_SW 5.4254 PG_D 1.0878 TRACER_2D 24.7418 REMAPPING 27.2644 Now I looked at GNU Fortran (7.3.0). Here my "stock" flags are quite boring (and all flags, not just the optimization ones): [Various options elided, the best was]: GNU Haswell NoFMA Repack: C_SW 2.4350 D_SW 9.7109 PG_D 0.7869 TRACER_2D 163.6474 REMAPPING 100.6820 So, my questions to you gurus are: Is there something I could try adding to my gfortran options that might help with this discrepancy between Intel AVX2 and GCC? Or perhaps I need to *remove* something (some flag kills the vectorizer)? The gcc 8 release is just around the corner, and a lot of improvements have been made to code generation, also for AVX2. You might want to give the current trunk (or the soon-to-be-released) release candidate, or the then newly released gcc8 a spin. Second, this performance gap with respect to Intel (a factor of 6.6 for your TRACER_2D routine) is dramatic. If anything like this persists in gcc8, the only way to get this fixed is to submit a bug report. Profile the code, try to reduce the code to something that shows the the problem (and that you can put in a bug report). Regards Thomas
