* Ryzen PPA znver1 optimizations @ 2019-03-08 7:56 Vanida Plamondon 2019-03-08 11:00 ` Richard Biener 0 siblings, 1 reply; 7+ messages in thread From: Vanida Plamondon @ 2019-03-08 7:56 UTC (permalink / raw) To: gcc 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ryzen PPA znver1 optimizations 2019-03-08 7:56 Ryzen PPA znver1 optimizations Vanida Plamondon @ 2019-03-08 11:00 ` Richard Biener 2019-03-08 11:28 ` Vanida Plamondon 0 siblings, 1 reply; 7+ messages in thread From: Richard Biener @ 2019-03-08 11:00 UTC (permalink / raw) To: Vanida Plamondon; +Cc: GCC Development 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ryzen PPA znver1 optimizations 2019-03-08 11:00 ` Richard Biener @ 2019-03-08 11:28 ` Vanida Plamondon 2019-03-08 20:58 ` Jonathan Wakely 0 siblings, 1 reply; 7+ messages in thread From: Vanida Plamondon @ 2019-03-08 11:28 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Development 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ryzen PPA znver1 optimizations 2019-03-08 11:28 ` Vanida Plamondon @ 2019-03-08 20:58 ` Jonathan Wakely 2019-03-08 22:00 ` Vanida Plamondon 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Wakely @ 2019-03-08 20:58 UTC (permalink / raw) To: Vanida Plamondon; +Cc: Richard Biener, GCC Development 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ryzen PPA znver1 optimizations 2019-03-08 20:58 ` Jonathan Wakely @ 2019-03-08 22:00 ` Vanida Plamondon 2019-03-08 22:44 ` Jonathan Wakely 0 siblings, 1 reply; 7+ messages in thread From: Vanida Plamondon @ 2019-03-08 22:00 UTC (permalink / raw) To: Jonathan Wakely; +Cc: GCC Development 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ryzen PPA znver1 optimizations 2019-03-08 22:00 ` Vanida Plamondon @ 2019-03-08 22:44 ` Jonathan Wakely 2019-03-08 22:59 ` Vanida Plamondon 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Wakely @ 2019-03-08 22:44 UTC (permalink / raw) To: Vanida Plamondon; +Cc: GCC Development 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ryzen PPA znver1 optimizations 2019-03-08 22:44 ` Jonathan Wakely @ 2019-03-08 22:59 ` Vanida Plamondon 0 siblings, 0 replies; 7+ messages in thread From: Vanida Plamondon @ 2019-03-08 22:59 UTC (permalink / raw) To: Jonathan Wakely; +Cc: GCC Development 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? > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-03-08 22:59 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-08 7:56 Ryzen PPA znver1 optimizations Vanida Plamondon 2019-03-08 11:00 ` Richard Biener 2019-03-08 11:28 ` Vanida Plamondon 2019-03-08 20:58 ` Jonathan Wakely 2019-03-08 22:00 ` Vanida Plamondon 2019-03-08 22:44 ` Jonathan Wakely 2019-03-08 22:59 ` Vanida Plamondon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).