Re: IBM z13 support for older GCCs
On Fri, 22 May 2015, Andreas Krebbel wrote: On 05/22/2015 10:22 AM, Richard Biener wrote: On Fri, 22 May 2015, Andreas Krebbel wrote: Hi, in order to get the IBM z13 support into present distros the Linux distributors asked me to get this stuff upstream into the older GCC branches first. This would ease the whole backporting efforts, interactions with other patches and would make sure that everybody uses the same code level. This would affect at least the GCC 4.8 and 5 branches but for continuity reasons it probably also should go into 4.9 then. The patchset requires only very minor common code changes and therefore imposes only a low risk for other platforms: recog: Increased max number of alternatives - v2 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html On branches you'd have to use unsigned HOST_WIDE_INT (where that might be 32bits on some hosts!). We still support hosts without uint64_t here. So this might already be a no-go. optabs: Fix vec_perm - V16QI middle end lowering. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html There is definitely some risk for S/390 but this again should be relatively low when compiling for CPU levels prio to z13. For the z13 support itself I've added a bunch of testcases but I've also run checks with about 1 automatically generated testcases not part of the patchset. We also ran the ABI comparison testsuite to compare the GCC and LLVM implementations regarding vector data types. Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well? I'm somewhat missing the point of backporting z13 support. ppc64le enablement was a different story (IBM basically saying ppc64-linux is dead), but surely all z13 machines can run non-z13 code just fine. s390x-linux-gnu is a secondary platform so I don't think we'd want to destabilize it (esp. on the 4.8 branch where I expect only one more release around the end of June with no chance to fix things up). So that's a no from me basically. But I'm willing to be convinced otherwise (not having looked into the z13 backend patches at all). Ok. What about GCC 5 branch? All arguments still apply apart from the fact that we'll have plenty of releases from the GCC 5 branch (and the alternatives patch is safe there). So for GCC 5 I'm willing to leave it to the architecture maintainers, but please wait for other RMs to chime in. Thanks, Richard. -Andreas- -- Richard Biener rguent...@suse.de SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
Re: IBM z13 support for older GCCs
On 05/22/2015 10:22 AM, Richard Biener wrote: On Fri, 22 May 2015, Andreas Krebbel wrote: Hi, in order to get the IBM z13 support into present distros the Linux distributors asked me to get this stuff upstream into the older GCC branches first. This would ease the whole backporting efforts, interactions with other patches and would make sure that everybody uses the same code level. This would affect at least the GCC 4.8 and 5 branches but for continuity reasons it probably also should go into 4.9 then. The patchset requires only very minor common code changes and therefore imposes only a low risk for other platforms: recog: Increased max number of alternatives - v2 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html On branches you'd have to use unsigned HOST_WIDE_INT (where that might be 32bits on some hosts!). We still support hosts without uint64_t here. So this might already be a no-go. optabs: Fix vec_perm - V16QI middle end lowering. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html There is definitely some risk for S/390 but this again should be relatively low when compiling for CPU levels prio to z13. For the z13 support itself I've added a bunch of testcases but I've also run checks with about 1 automatically generated testcases not part of the patchset. We also ran the ABI comparison testsuite to compare the GCC and LLVM implementations regarding vector data types. Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well? I'm somewhat missing the point of backporting z13 support. ppc64le enablement was a different story (IBM basically saying ppc64-linux is dead), but surely all z13 machines can run non-z13 code just fine. s390x-linux-gnu is a secondary platform so I don't think we'd want to destabilize it (esp. on the 4.8 branch where I expect only one more release around the end of June with no chance to fix things up). So that's a no from me basically. But I'm willing to be convinced otherwise (not having looked into the z13 backend patches at all). Ok. What about GCC 5 branch? -Andreas-
Re: IBM z13 support for older GCCs
On Fri, 22 May 2015, Andreas Krebbel wrote: Hi, in order to get the IBM z13 support into present distros the Linux distributors asked me to get this stuff upstream into the older GCC branches first. This would ease the whole backporting efforts, interactions with other patches and would make sure that everybody uses the same code level. This would affect at least the GCC 4.8 and 5 branches but for continuity reasons it probably also should go into 4.9 then. The patchset requires only very minor common code changes and therefore imposes only a low risk for other platforms: recog: Increased max number of alternatives - v2 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html On branches you'd have to use unsigned HOST_WIDE_INT (where that might be 32bits on some hosts!). We still support hosts without uint64_t here. So this might already be a no-go. optabs: Fix vec_perm - V16QI middle end lowering. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html There is definitely some risk for S/390 but this again should be relatively low when compiling for CPU levels prio to z13. For the z13 support itself I've added a bunch of testcases but I've also run checks with about 1 automatically generated testcases not part of the patchset. We also ran the ABI comparison testsuite to compare the GCC and LLVM implementations regarding vector data types. Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well? I'm somewhat missing the point of backporting z13 support. ppc64le enablement was a different story (IBM basically saying ppc64-linux is dead), but surely all z13 machines can run non-z13 code just fine. s390x-linux-gnu is a secondary platform so I don't think we'd want to destabilize it (esp. on the 4.8 branch where I expect only one more release around the end of June with no chance to fix things up). So that's a no from me basically. But I'm willing to be convinced otherwise (not having looked into the z13 backend patches at all). CCing that other release manager we have as well. Thanks, Richard. -- Richard Biener rguent...@suse.de SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
IBM z13 support for older GCCs
Hi, in order to get the IBM z13 support into present distros the Linux distributors asked me to get this stuff upstream into the older GCC branches first. This would ease the whole backporting efforts, interactions with other patches and would make sure that everybody uses the same code level. This would affect at least the GCC 4.8 and 5 branches but for continuity reasons it probably also should go into 4.9 then. The patchset requires only very minor common code changes and therefore imposes only a low risk for other platforms: recog: Increased max number of alternatives - v2 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html optabs: Fix vec_perm - V16QI middle end lowering. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html There is definitely some risk for S/390 but this again should be relatively low when compiling for CPU levels prio to z13. For the z13 support itself I've added a bunch of testcases but I've also run checks with about 1 automatically generated testcases not part of the patchset. We also ran the ABI comparison testsuite to compare the GCC and LLVM implementations regarding vector data types. Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well? Bye, -Andreas-
Re: IBM z13 support for older GCCs
On Fri, May 22, 2015 at 10:22:07AM +0200, Richard Biener wrote: I'm somewhat missing the point of backporting z13 support. ppc64le enablement was a different story (IBM basically saying ppc64-linux is dead), but surely all z13 machines can run non-z13 code just fine. s390x-linux-gnu is a secondary platform so I don't think we'd want to destabilize it (esp. on the 4.8 branch where I expect only one more release around the end of June with no chance to fix things up). So that's a no from me basically. But I'm willing to be convinced otherwise (not having looked into the z13 backend patches at all). Yeah, agreed, I'd find that too risky and the 35 alternatives thing (and other generic code changes) make it even less desirable. Say on i?86/x86_64 new ISA additions weren't backported to release branches either, on other branches too. ppc64le has been indeed an exception, and the power8 enablement (as opposed to just le enablement) has been backported primarily because ppc64le states that power8 is the minimum supported architecture. Jakub
Re: IBM z13 support for older GCCs
On Fri, May 22, 2015 at 12:43:14PM +, Joseph Myers wrote: On Fri, 22 May 2015, Richard Biener wrote: All arguments still apply apart from the fact that we'll have plenty of releases from the GCC 5 branch (and the alternatives patch is safe there). So for GCC 5 I'm willing to leave it to the architecture maintainers, but please wait for other RMs to chime in. Leaving to architecture maintainers is OK with me for GCC 5. Ok. Jakub
Re: IBM z13 support for older GCCs
On Fri, 22 May 2015, Richard Biener wrote: All arguments still apply apart from the fact that we'll have plenty of releases from the GCC 5 branch (and the alternatives patch is safe there). So for GCC 5 I'm willing to leave it to the architecture maintainers, but please wait for other RMs to chime in. Leaving to architecture maintainers is OK with me for GCC 5. -- Joseph S. Myers jos...@codesourcery.com
Re: IBM z13 support for older GCCs
On 05/22/2015 10:54 AM, Richard Biener wrote: On Fri, 22 May 2015, Andreas Krebbel wrote: On 05/22/2015 10:22 AM, Richard Biener wrote: On Fri, 22 May 2015, Andreas Krebbel wrote: Hi, in order to get the IBM z13 support into present distros the Linux distributors asked me to get this stuff upstream into the older GCC branches first. This would ease the whole backporting efforts, interactions with other patches and would make sure that everybody uses the same code level. This would affect at least the GCC 4.8 and 5 branches but for continuity reasons it probably also should go into 4.9 then. The patchset requires only very minor common code changes and therefore imposes only a low risk for other platforms: recog: Increased max number of alternatives - v2 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html On branches you'd have to use unsigned HOST_WIDE_INT (where that might be 32bits on some hosts!). We still support hosts without uint64_t here. So this might already be a no-go. optabs: Fix vec_perm - V16QI middle end lowering. https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html There is definitely some risk for S/390 but this again should be relatively low when compiling for CPU levels prio to z13. For the z13 support itself I've added a bunch of testcases but I've also run checks with about 1 automatically generated testcases not part of the patchset. We also ran the ABI comparison testsuite to compare the GCC and LLVM implementations regarding vector data types. Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well? I'm somewhat missing the point of backporting z13 support. ppc64le enablement was a different story (IBM basically saying ppc64-linux is dead), but surely all z13 machines can run non-z13 code just fine. s390x-linux-gnu is a secondary platform so I don't think we'd want to destabilize it (esp. on the 4.8 branch where I expect only one more release around the end of June with no chance to fix things up). So that's a no from me basically. But I'm willing to be convinced otherwise (not having looked into the z13 backend patches at all). Ok. What about GCC 5 branch? All arguments still apply apart from the fact that we'll have plenty of releases from the GCC 5 branch (and the alternatives patch is safe there). So for GCC 5 I'm willing to leave it to the architecture maintainers, but please wait for other RMs to chime in. I'll set a grace period of let's say a month or so and commit the patches as long as no veto comes up until then. Ok? -Andreas-
