This is the mail archive of the
mailing list for the GCC project.
Re: IBM z13 support for older GCCs
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 22 May 2015 20:24:03 +0200
- Subject: Re: IBM z13 support for older GCCs
- Authentication-results: sourceware.org; auth=none
- References: <555EE48E dot 9090209 at linux dot vnet dot ibm dot com> <alpine dot LSU dot 2 dot 11 dot 1505221015270 dot 30088 at zhemvz dot fhfr dot qr> <555EEB49 dot 4020709 at linux dot vnet dot ibm dot com> <alpine dot LSU dot 2 dot 11 dot 1505221052540 dot 30088 at zhemvz dot fhfr dot qr>
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:
>>>> 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
>>> 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.
>>>> 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 10000 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?