Re: libmvec in gcc to have vector math in fortran

[Florian Weimer]

* Richard Biener:

> 'pure' makes it pure but there doesn't seem to be a way to make it const?

Does Fortran support setting the rounding mode?

In C, sin is not const because it depends on the current rounding
mode.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 9:59 AM Florian Weimer  wrote:
>
> * Richard Biener:
>
> > 'pure' makes it pure but there doesn't seem to be a way to make it const?
>
> Does Fortran support setting the rounding mode?
>
> In C, sin is not const because it depends on the current rounding
> mode.

It is (well, the GCC builtin) by default because -fno-rounding-math
is default.  Note that using "reads global memory" (aka pure and not
const) is a bit of a stretch for "accesses the FP state" ;)  It's basically
a workaround for the fact that GCC doesn't "implement" FENV access.

That said, good to see some glibc folks jump in on this thread.
I'd like to see glibc provide a fortran intrinsic header advertising
the libmvec routines it has.  We probably do need some gfortran
adjustments here but I think that glibc advertising is better than
hard-coding lists into GCC (like we do for some targets with
their -mveclibabi= option).

Richard.

Re: libmvec in gcc to have vector math in fortran

[Szabolcs Nagy]

On 15/06/18 08:59, Florian Weimer wrote:

* Richard Biener:


'pure' makes it pure but there doesn't seem to be a way to make it const?


Does Fortran support setting the rounding mode?



yes, but vec math is only enabled with -ffast-math (so it can
assume -fno-rounding-math)


In C, sin is not const because it depends on the current rounding
mode.



hm i don't see const in glibc even in case of -ffast-math compilation,
i wonder if that can be changed.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 10:39 AM Szabolcs Nagy  wrote:
>
> On 15/06/18 08:59, Florian Weimer wrote:
> > * Richard Biener:
> >
> >> 'pure' makes it pure but there doesn't seem to be a way to make it const?
> >
> > Does Fortran support setting the rounding mode?
> >
>
> yes, but vec math is only enabled with -ffast-math (so it can
> assume -fno-rounding-math)
>
> > In C, sin is not const because it depends on the current rounding
> > mode.
> >
>
> hm i don't see const in glibc even in case of -ffast-math compilation,
> i wonder if that can be changed.

For sin() it also depends on -fno-math-errno (default for fortran) given
sin() may set errno according to the manpage (that means it isn't
even pure by default).

Richard.

Re: libmvec in gcc to have vector math in fortran

[Florian Weimer]

* Richard Biener:

> That said, good to see some glibc folks jump in on this thread.
> I'd like to see glibc provide a fortran intrinsic header advertising
> the libmvec routines it has.  We probably do need some gfortran
> adjustments here but I think that glibc advertising is better than
> hard-coding lists into GCC (like we do for some targets with
> their -mveclibabi= option).

The advantage of putting into GCC is that it will work irrespective of
the installed glibc header version, so if we get this going:

  

you could use libmvec along with really old glibcs (probably as far
back as 2.12, maybe even older).

But then we might into a different direction altogether.

Another question is wheter the Fortran header can be generated by
something like -fdump-ada-spec, so that we don't have to maintain it
separately from the C header.

Re: libmvec in gcc to have vector math in fortran

[Richard Biener]

On Fri, Jun 15, 2018 at 11:08 AM Florian Weimer  wrote:
>
> * Richard Biener:
>
> > That said, good to see some glibc folks jump in on this thread.
> > I'd like to see glibc provide a fortran intrinsic header advertising
> > the libmvec routines it has.  We probably do need some gfortran
> > adjustments here but I think that glibc advertising is better than
> > hard-coding lists into GCC (like we do for some targets with
> > their -mveclibabi= option).
>
> The advantage of putting into GCC is that it will work irrespective of
> the installed glibc header version, so if we get this going:
>
>   
>
> you could use libmvec along with really old glibcs (probably as far
> back as 2.12, maybe even older).

Well, ok - I obviously meant bundling the header with libmvec, not with
glibc (which currently is the same).

Putting it into GCC means that you have mismatches in both directions.

I was also considering to somehow auto-generate a header based
on what the C headers advertise at GCC install time.
[or put a C parser into the fortran frontend, eh...]

> But then we might into a different direction altogether.
>
> Another question is wheter the Fortran header can be generated by
> something like -fdump-ada-spec, so that we don't have to maintain it
> separately from the C header.

Sure, see above - I think that's possible and it doesn't have to be as
complicated as -fdump-ada-spec.  Instead a simple script in your
favorite language will do the job.

First and foremost we need a syntax that actually works for the
Fortran frontend and a way to automatically include this special
header / module.

Richard.

Re: How to get GCC on par with ICC?

[Wilco Dijkstra]

Martin wrote:

> Keep in mind that when discussing FP benchmarks, the used math library
> can be (almost) as important as the compiler.  In the case of 481.wrf,
> we found that the GCC 8 + glibc 2.26 (so the "out-of-the box" GNU)
> performance is about 70% of ICC's.  When we just linked against AMD's
> libm, we got to 83%. When we instructed GCC to generate calls to Intel's
> SVML library and linked against it, we got to 91%.  Using both SVML and
> AMD's libm, we achieved 93%.
>
> That means that there likely still is 7% to be gained from more clever
> optimizations in GCC but the real problem is in GNU libm.  And 481.wrf
> is perhaps the most extreme example but definitely not the only one.

You really should retry with GLIBC 2.27 since several key math functions were
rewritten from scratch by Szabolcs Nagy (all in generic C code), resulting in 
huge
performance gains on all targets (eg. wrf improved over 50%).

I fixed several double precision functions in current GLIBC to avoid extremely 
bad
performance which had been complained about for years. There are more math
functions on the way, so the GNU libm will not only catch up, but become the 
fastest
math library available.

Wilco

Vectorizer size preferences (-mprefer-* on x86)

[Richard Biener]

Hi,

I'm in the process of changing the vectorizer to consider all
vector sizes as advertised by targetm.autovectorize_vector_sizes
and to decide which one to use based on its cost model.

I expect that to make sense for example when choosing between
AVX128 and AVX256 since the latter may have penalties for
cross-lane operations which the former lacks.

Now while the option -mprefer-* and the documentation (to
some extent) suggests that the user communicates a preference
the actual implementation in the x86 backend uses -mprefer-*
to disable the use of larger vector sizes.  That also makes
targetm.preferred_simd_mode somewhat redundant.

In the light of using the cost model to decide on the vector
width used how should we go forward here?

I would suggest to more clearly document that -mprefer-*
will disable the use of larger vector sizes and that smaller
vector sizes might be used if costs tell us to do so (or loops
do not roll enough).  Implementation-wise the size chosen
by targetm.preferred_simd_mode could be used as tie-breaker
in case equal costs are computed.

In the (distant?) future we might want to support mixed-size
vectorization which makes all this even more complicated.
Still having -mprefer-* disabling vector sizes makes sense
here?

Thanks,
Richard.

Re: Vectorizer size preferences (-mprefer-* on x86)

[Jan Hubicka]

> 
> Hi,
> 
> I'm in the process of changing the vectorizer to consider all
> vector sizes as advertised by targetm.autovectorize_vector_sizes
> and to decide which one to use based on its cost model.
> 
> I expect that to make sense for example when choosing between
> AVX128 and AVX256 since the latter may have penalties for
> cross-lane operations which the former lacks.
> 
> Now while the option -mprefer-* and the documentation (to
> some extent) suggests that the user communicates a preference
> the actual implementation in the x86 backend uses -mprefer-*
> to disable the use of larger vector sizes.  That also makes
> targetm.preferred_simd_mode somewhat redundant.
> 
> In the light of using the cost model to decide on the vector
> width used how should we go forward here?
> 
> I would suggest to more clearly document that -mprefer-*
> will disable the use of larger vector sizes and that smaller
> vector sizes might be used if costs tell us to do so (or loops
> do not roll enough).  Implementation-wise the size chosen
> by targetm.preferred_simd_mode could be used as tie-breaker
> in case equal costs are computed.

I suppose one useful meaning of -mpreffer would be to overwrite
the decision heuristics to only consider the mode specified.
(it is what we do at the moment anyway, right?)
So one can use it in the case your heuristics makes wrong choice.
But disabling only bigger vector sizes makes sense to me as well.

Honza
> 
> In the (distant?) future we might want to support mixed-size
> vectorization which makes all this even more complicated.
> Still having -mprefer-* disabling vector sizes makes sense
> here?
> 
> Thanks,
> Richard.

Re: Vectorizer size preferences (-mprefer-* on x86)

[Richard Biener]

On Fri, 15 Jun 2018, Jan Hubicka wrote:

> > 
> > Hi,
> > 
> > I'm in the process of changing the vectorizer to consider all
> > vector sizes as advertised by targetm.autovectorize_vector_sizes
> > and to decide which one to use based on its cost model.
> > 
> > I expect that to make sense for example when choosing between
> > AVX128 and AVX256 since the latter may have penalties for
> > cross-lane operations which the former lacks.
> > 
> > Now while the option -mprefer-* and the documentation (to
> > some extent) suggests that the user communicates a preference
> > the actual implementation in the x86 backend uses -mprefer-*
> > to disable the use of larger vector sizes.  That also makes
> > targetm.preferred_simd_mode somewhat redundant.
> > 
> > In the light of using the cost model to decide on the vector
> > width used how should we go forward here?
> > 
> > I would suggest to more clearly document that -mprefer-*
> > will disable the use of larger vector sizes and that smaller
> > vector sizes might be used if costs tell us to do so (or loops
> > do not roll enough).  Implementation-wise the size chosen
> > by targetm.preferred_simd_mode could be used as tie-breaker
> > in case equal costs are computed.
> 
> I suppose one useful meaning of -mpreffer would be to overwrite
> the decision heuristics to only consider the mode specified.
> (it is what we do at the moment anyway, right?)

At the moment if we can vectorize using that mode we will use it.
Only if vectorization fails for whatever reason we are trying
alternate modes as speficied by targetm.autovectorize_vector_sizes.

> So one can use it in the case your heuristics makes wrong choice.
> But disabling only bigger vector sizes makes sense to me as well.

Note with the vectorizer update there is no way to tell it
it should not "prefer" any specific size.  The
preferred_simd_mode was there first and only later came
autovectorize_vector_sizes which after recent changes now
has the sizes ordered.  But the vectorizer starts with
the size chosen by preferred_simd_mode, not honoring
the autovectorize_vector_sizes order for the first vector
size but only the following.

Completely overriding the cost comparison and sticking to
the current behavior would require another mechanism.

Maybe we should re-thing the two target hooks currently
used in this area.

Richard.

Re: Vectorizer size preferences (-mprefer-* on x86)

[Richard Earnshaw (lists)]

On 15/06/18 12:48, Richard Biener wrote:
> 
> Hi,
> 
> I'm in the process of changing the vectorizer to consider all
> vector sizes as advertised by targetm.autovectorize_vector_sizes
> and to decide which one to use based on its cost model.
> 
> I expect that to make sense for example when choosing between
> AVX128 and AVX256 since the latter may have penalties for
> cross-lane operations which the former lacks.
> 
> Now while the option -mprefer-* and the documentation (to
> some extent) suggests that the user communicates a preference
> the actual implementation in the x86 backend uses -mprefer-*
> to disable the use of larger vector sizes.  That also makes
> targetm.preferred_simd_mode somewhat redundant.
> 
> In the light of using the cost model to decide on the vector
> width used how should we go forward here?
> 
> I would suggest to more clearly document that -mprefer-*
> will disable the use of larger vector sizes and that smaller
> vector sizes might be used if costs tell us to do so (or loops
> do not roll enough).  Implementation-wise the size chosen
> by targetm.preferred_simd_mode could be used as tie-breaker
> in case equal costs are computed.
> 
> In the (distant?) future we might want to support mixed-size
> vectorization which makes all this even more complicated.
> Still having -mprefer-* disabling vector sizes makes sense
> here?
> 
> Thanks,
> Richard.
> 

Could you approximate here what we've done for Arm -mfpu= - add an
'auto' option and make it the default.  Over time you then deprecate
other settings and eventually drop them, leaving only the default.

R.

Re: How to get GCC on par with ICC?

[Jeff Law]

On 06/15/2018 05:39 AM, Wilco Dijkstra wrote:
> Martin wrote:
> 
>> Keep in mind that when discussing FP benchmarks, the used math library
>> can be (almost) as important as the compiler.  In the case of 481.wrf,
>> we found that the GCC 8 + glibc 2.26 (so the "out-of-the box" GNU)
>> performance is about 70% of ICC's.  When we just linked against AMD's
>> libm, we got to 83%. When we instructed GCC to generate calls to Intel's
>> SVML library and linked against it, we got to 91%.  Using both SVML and
>> AMD's libm, we achieved 93%.
>>
>> That means that there likely still is 7% to be gained from more clever
>> optimizations in GCC but the real problem is in GNU libm.  And 481.wrf
>> is perhaps the most extreme example but definitely not the only one.
> 
> You really should retry with GLIBC 2.27 since several key math functions were
> rewritten from scratch by Szabolcs Nagy (all in generic C code), resulting in 
> huge
> performance gains on all targets (eg. wrf improved over 50%).
> 
> I fixed several double precision functions in current GLIBC to avoid 
> extremely bad
> performance which had been complained about for years. There are more math
> functions on the way, so the GNU libm will not only catch up, but become the 
> fastest
> math library available.
And resolution on -fno-math-errno as the default.  Setting errno can be
more expensive than people realize.

Jeff

Re: How to get GCC on par with ICC?

[Joseph Myers]

On Fri, 15 Jun 2018, Jeff Law wrote:

> And resolution on -fno-math-errno as the default.  Setting errno can be
> more expensive than people realize.

I don't think I saw any version of the -fno-math-errno patch proposal that 
included the testsuite updates I'd expect.  Certainly 
gcc.dg/torture/pr68264.c tests libm functions setting errno and would need 
to use -fmath-errno explicitly, but it seems likely there are other tests 
involving built-in functions that in fact only test what they're intended 
to test given -fmath-errno; tests using libm functions without explicit 
-ffast-math / -fmath-errno / -fno-math-errno would need review (and there 
should be new tests for optimizations that are only valid given 
-fno-math-errno).

-- 
Joseph S. Myers
jos...@codesourcery.com

Gcc Plugin Api

[Shubham Narlawar]

Hello all, I have been figuring out to work on some project. So while
searching I found GCC Plugin API project quite interesting.
So, please can I get some more information and links about gcc Plugin API
project.
Can anyone help me please.

Re: Gcc Plugin Api

[U.Mutlu]

Shubham Narlawar wrote on 06/15/2018 08:01 PM:

Hello all, I have been figuring out to work on some project. So while
searching I found GCC Plugin API project quite interesting.
So, please can I get some more information and links about gcc Plugin API
project.
Can anyone help me please.


Here's an interessting step-by-step sample plugin project in 3 parts:
  https://thinkingeek.com/2015/08/16/a-simple-plugin-for-gcc-part-1/
  https://thinkingeek.com/2015/08/16/simple-plugin-gcc-part-2/
  https://thinkingeek.com/2015/08/17/simple-plugin-gcc-part-3/

And of course the official docs:
  https://gcc.gnu.org/wiki/plugins
  https://gcc.gnu.org/onlinedocs/gccint/Plugins.html

...

Re: libmvec in gcc to have vector math in fortran

[Thomas Koenig]

Hi Richard,


First and foremost we need a syntax that actually works for the
Fortran frontend and a way to automatically include this special
header / module.


I can imagine parsing the relevant headers while compiling gfortran
and generating C code from it, which could then be #included in the
compiler source code. It should be possible to extend mathbuiltins.def
that way.

How does that sound?

Regards

Thomas

Re: libmvec in gcc to have vector math in fortran

[Joseph Myers]

On Fri, 15 Jun 2018, Thomas Koenig wrote:

> Hi Richard,
> 
> > First and foremost we need a syntax that actually works for the
> > Fortran frontend and a way to automatically include this special
> > header / module.
> 
> I can imagine parsing the relevant headers while compiling gfortran
> and generating C code from it, which could then be #included in the
> compiler source code. It should be possible to extend mathbuiltins.def
> that way.

The libmvec functions present depend on the multilib (for example, glibc 
only currently supports them for x86_64, not for 32-bit x86).  Given this 
multilib dependence, parsing the glibc headers when building the compiler 
itself is probably not a sensible option.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-8-20180615 is now available

[gccadmin]

Snapshot gcc-8-20180615 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180615/
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 261667

You'll find:

 gcc-8-20180615.tar.xzComplete GCC

  SHA256=f035b84cebfe1fcb85a32655efbcc56fe2630d3cc86cdb277e356f4cf151b268
  SHA1=4dedc8b5c1fa11798301ddc8dae1d6107f9e0896

Diffs from 8-20180608 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.