Ryzen PPA znver1 optimizations

Ryzen PPA znver1 optimizations

[Vanida Plamondon]

I have been working on some PPA's that will provide standard Ubuntu
and Linux Mint packages that are compiled with the znver1 cpu
optimisations (Ryzen CPU). It has been quite tedious (though not
particularly hard) to modify existing packages to be compiled with
"-march=znver1" cflags and cxxflags, and since I started creating a
toolchain to make the builds in the PPAs compile more reliably while
producing broken less packages, I decided to modify GCC to always spit
out ryzen optimised code automatically regardless of what code is
thrown at it.

I changed each instance of =generic in gcc/config.gcc to =znver1, and
each instance of cpu=<something> to cpu=znver1, and each instance of
arch=<something> that wasn't i386, i486, i586, i686, i786, x86-64, or
x86_64 to arch=znver1.

So what I think will happen is that I will set a PPA with a dependency
on the PPA with the modified GCC, and any package I upload/copy to the
aforementioned PPA that is compiling to x86 code will compile as
though I set the "-march=znver1" option. Does anyone know whether or
not this is going to work the way I think it will, or know how I can
test to see if such is the case with the resulting binary packages?

Also, is there a better way to do what I am trying to do?

Re: Ryzen PPA znver1 optimizations

[Richard Biener]

On Fri, Mar 8, 2019 at 8:56 AM Vanida Plamondon
<vanida.plamondon@gmail.com> wrote:
>
> I have been working on some PPA's that will provide standard Ubuntu
> and Linux Mint packages that are compiled with the znver1 cpu
> optimisations (Ryzen CPU). It has been quite tedious (though not
> particularly hard) to modify existing packages to be compiled with
> "-march=znver1" cflags and cxxflags, and since I started creating a
> toolchain to make the builds in the PPAs compile more reliably while
> producing broken less packages, I decided to modify GCC to always spit
> out ryzen optimised code automatically regardless of what code is
> thrown at it.
>
> I changed each instance of =generic in gcc/config.gcc to =znver1, and
> each instance of cpu=<something> to cpu=znver1, and each instance of
> arch=<something> that wasn't i386, i486, i586, i686, i786, x86-64, or
> x86_64 to arch=znver1.

You can configure with --with-arch=znver1 --with-tune=znver1 to
achieve the same effect.

> So what I think will happen is that I will set a PPA with a dependency
> on the PPA with the modified GCC, and any package I upload/copy to the
> aforementioned PPA that is compiling to x86 code will compile as
> though I set the "-march=znver1" option. Does anyone know whether or
> not this is going to work the way I think it will, or know how I can
> test to see if such is the case with the resulting binary packages?
>
> Also, is there a better way to do what I am trying to do?

Re: Ryzen PPA znver1 optimizations

[Vanida Plamondon]

I realise that, however, debian packages seem to use multiple build
systems (automake, dh_automake, ninja, etc.), and have no standard
(that is adhered to), for setting up each build environment.
Additionally, some packages seem to throw their build configuration
setup throughout multiple files that are difficult to pin down, and
usually have little documentation. I am trying to set up a toolchain
that automatically fetches upstream sources when updated, updates the
changelog to reflect that the package is znver1 optimised, and
automatically compiles the package with the znver1 optimisations. Even
worse, many packages use different environmental variables, and some
even unset some of such standard variables.

This means I need to setup gcc so that any x86 code thrown at it is
automatically compiled with znver1 optimisations to overcome these
limitations. I have no idea if the config.gcc modification works as I
don't know if it works the way I think it works, and I haven't figured
out how to test the packages I have compiled with gcc.

On Fri, Mar 8, 2019 at 4:00 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Fri, Mar 8, 2019 at 8:56 AM Vanida Plamondon
> <vanida.plamondon@gmail.com> wrote:
> >
> > I have been working on some PPA's that will provide standard Ubuntu
> > and Linux Mint packages that are compiled with the znver1 cpu
> > optimisations (Ryzen CPU). It has been quite tedious (though not
> > particularly hard) to modify existing packages to be compiled with
> > "-march=znver1" cflags and cxxflags, and since I started creating a
> > toolchain to make the builds in the PPAs compile more reliably while
> > producing broken less packages, I decided to modify GCC to always spit
> > out ryzen optimised code automatically regardless of what code is
> > thrown at it.
> >
> > I changed each instance of =generic in gcc/config.gcc to =znver1, and
> > each instance of cpu=<something> to cpu=znver1, and each instance of
> > arch=<something> that wasn't i386, i486, i586, i686, i786, x86-64, or
> > x86_64 to arch=znver1.
>
> You can configure with --with-arch=znver1 --with-tune=znver1 to
> achieve the same effect.
>
> > So what I think will happen is that I will set a PPA with a dependency
> > on the PPA with the modified GCC, and any package I upload/copy to the
> > aforementioned PPA that is compiling to x86 code will compile as
> > though I set the "-march=znver1" option. Does anyone know whether or
> > not this is going to work the way I think it will, or know how I can
> > test to see if such is the case with the resulting binary packages?
> >
> > Also, is there a better way to do what I am trying to do?

Re: Ryzen PPA znver1 optimizations

[Jonathan Wakely]

On Fri, 8 Mar 2019 at 11:28, Vanida Plamondon
<vanida.plamondon@gmail.com> wrote:
>
> I realise that, however, debian packages seem to use multiple build
> systems (automake, dh_automake, ninja, etc.), and have no standard
> (that is adhered to), for setting up each build environment.
> Additionally, some packages seem to throw their build configuration
> setup throughout multiple files that are difficult to pin down, and
> usually have little documentation. I am trying to set up a toolchain
> that automatically fetches upstream sources when updated, updates the
> changelog to reflect that the package is znver1 optimised, and
> automatically compiles the package with the znver1 optimisations. Even
> worse, many packages use different environmental variables, and some
> even unset some of such standard variables.
>
> This means I need to setup gcc so that any x86 code thrown at it is
> automatically compiled with znver1 optimisations to overcome these
> limitations.

That's what the configure options Richi showed will do.

N.B. he didn't say to use -march=znver1 when compiling with GCC, he
said to use --with-arch=znver1 when configuring GCC itself.

Re: Ryzen PPA znver1 optimizations

[Vanida Plamondon]

OK, so it seems I need to give more information to clarify what I am
trying to do.

I am not invoking or configuring gcc directly. I am creating debian
source code packages which are then dispatched to launchpad.net, which
then automatically compiles and builds my package based on the debian
configuration files. I am trying to created a toolchain that does this
automatically while also setting the znver1 optimisations
automatically.

As far as I can tell, the --with-arch= and --with-cpu= gcc
configuration options set defaults, and do not enforce compilation
with these options if a package specifically configures a different
cpu or architecture, so correct me if I am wrong. Regardless, I do
have those options set in the various versions of gcc in my toolchain,
but I need gcc to ignore rogue packages that configure to a different
x86 architecture. My PPAs only target znver1 for x86 code, so nothing
breaks if my toolchain ignores other x86 architectures.

Since I am trying to create an automatic toolchain, it would be much
easier to have a gcc that ignores non-default x86 configuration
options then it is to try to create a script that finds, catches, and
corrects an upstream package that uses a non-default configuration.

If the --with-arch= and --with-cpu= gcc configuration options cause
gcc to ignore non-default configure options, then please, let me know.

Otherwise, I would like someone to tell me if my proposed modification
will work as I expect, and If someone has a better way, I need an
explanation so I know if the proposed solution is going to work the
way I want.

On Fri, Mar 8, 2019 at 1:58 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Fri, 8 Mar 2019 at 11:28, Vanida Plamondon
> <vanida.plamondon@gmail.com> wrote:
> >
> > I realise that, however, debian packages seem to use multiple build
> > systems (automake, dh_automake, ninja, etc.), and have no standard
> > (that is adhered to), for setting up each build environment.
> > Additionally, some packages seem to throw their build configuration
> > setup throughout multiple files that are difficult to pin down, and
> > usually have little documentation. I am trying to set up a toolchain
> > that automatically fetches upstream sources when updated, updates the
> > changelog to reflect that the package is znver1 optimised, and
> > automatically compiles the package with the znver1 optimisations. Even
> > worse, many packages use different environmental variables, and some
> > even unset some of such standard variables.
> >
> > This means I need to setup gcc so that any x86 code thrown at it is
> > automatically compiled with znver1 optimisations to overcome these
> > limitations.
>
> That's what the configure options Richi showed will do.
>
> N.B. he didn't say to use -march=znver1 when compiling with GCC, he
> said to use --with-arch=znver1 when configuring GCC itself.

Re: Ryzen PPA znver1 optimizations

[Jonathan Wakely]

On Fri, 8 Mar 2019 at 22:00, Vanida Plamondon
<vanida.plamondon@gmail.com> wrote:
>
> OK, so it seems I need to give more information to clarify what I am
> trying to do.
>
> I am not invoking or configuring gcc directly.

(If you're creating a toolchain then surely you're configuring GCC.)

> I am creating debian
> source code packages which are then dispatched to launchpad.net, which
> then automatically compiles and builds my package based on the debian
> configuration files. I am trying to created a toolchain that does this
> automatically while also setting the znver1 optimisations
> automatically.
>
> As far as I can tell, the --with-arch= and --with-cpu= gcc
> configuration options set defaults, and do not enforce compilation
> with these options if a package specifically configures a different
> cpu or architecture, so correct me if I am wrong.

If by "configures a different cpu or architecture" you mean "uses the
-march option when invoking GCC" then you're correct.

Using --with-arch=znver1 will make GCC automatically select that
architecture. But it won't prevent that automatic selection being
overridden by an explicit -march option.


> Regardless, I do
> have those options set in the various versions of gcc in my toolchain,
> but I need gcc to ignore rogue packages that configure to a different
> x86 architecture. My PPAs only target znver1 for x86 code, so nothing
> breaks if my toolchain ignores other x86 architectures.
>
> Since I am trying to create an automatic toolchain, it would be much
> easier to have a gcc that ignores non-default x86 configuration
> options then it is to try to create a script that finds, catches, and
> corrects an upstream package that uses a non-default configuration.

Yes, that does seem simpler.

> If the --with-arch= and --with-cpu= gcc configuration options cause
> gcc to ignore non-default configure options, then please, let me know.

I find this use of "configure options" confusing too. You're talking
about flags passed to GCC when invoking it, not "configure options",
right?

Re: Ryzen PPA znver1 optimizations

[Vanida Plamondon]

Correct. It's hard to nail down the right terminology when I'm learning by
doing. I want GCC to ignore x86 flags that aren't znver1, and keep znver1
as the default.

On Fri, Mar 8, 2019, 3:44 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On Fri, 8 Mar 2019 at 22:00, Vanida Plamondon
> <vanida.plamondon@gmail.com> wrote:
> >
> > OK, so it seems I need to give more information to clarify what I am
> > trying to do.
> >
> > I am not invoking or configuring gcc directly.
>
> (If you're creating a toolchain then surely you're configuring GCC.)
>
> > I am creating debian
> > source code packages which are then dispatched to launchpad.net, which
> > then automatically compiles and builds my package based on the debian
> > configuration files. I am trying to created a toolchain that does this
> > automatically while also setting the znver1 optimisations
> > automatically.
> >
> > As far as I can tell, the --with-arch= and --with-cpu= gcc
> > configuration options set defaults, and do not enforce compilation
> > with these options if a package specifically configures a different
> > cpu or architecture, so correct me if I am wrong.
>
> If by "configures a different cpu or architecture" you mean "uses the
> -march option when invoking GCC" then you're correct.
>
> Using --with-arch=znver1 will make GCC automatically select that
> architecture. But it won't prevent that automatic selection being
> overridden by an explicit -march option.
>
>
> > Regardless, I do
> > have those options set in the various versions of gcc in my toolchain,
> > but I need gcc to ignore rogue packages that configure to a different
> > x86 architecture. My PPAs only target znver1 for x86 code, so nothing
> > breaks if my toolchain ignores other x86 architectures.
> >
> > Since I am trying to create an automatic toolchain, it would be much
> > easier to have a gcc that ignores non-default x86 configuration
> > options then it is to try to create a script that finds, catches, and
> > corrects an upstream package that uses a non-default configuration.
>
> Yes, that does seem simpler.
>
> > If the --with-arch= and --with-cpu= gcc configuration options cause
> > gcc to ignore non-default configure options, then please, let me know.
>
> I find this use of "configure options" confusing too. You're talking
> about flags passed to GCC when invoking it, not "configure options",
> right?
>