GOARCH ppc64 big endian future

[Lynn Boger]

I'd like to suggest we make a change to the implementation for GOARCH ppc64 big endian.

Currently there is a requirement that ppc64 big endian remain compatible with the power5 instruction set.  Now as we plan to improve performance for ppc64le by leveraging more of the new instruction sets (power8, power9, VMX, VSX) that requires more work to maintain that power5 compatibility for ppc64 big endian.

The simple solution would be to just lift that restriction so that ppc64 big endian can use the same instruction set as ppc64le.

However, since ppc64 big endian is still not fully supported for external linking and considered an experimental port, perhaps it should just be dropped as a supported GOARCH, leaving support for ppc64le only.

[mun...@ca.ibm.com]

Would it solve some of your problems if it was easier to specify which instruction set extensions an Op and/or SSA rule requires?

Conditional sections in the SSA rule files would achieve this I think and I believe ARM could use the same mechanism for different GOARM values. We could also use it to disable some of the more aggressive optimizations in noopt mode.

Something like:

(Op x) -> (OldOp x)
if arch == "ppc64le" {
  (OldOp x) -> (NewOp x)
  (NewOp x) && some_condition -> (SuperOp x)
}

The generator would then just place the code to execute the rule inside the if statement, like so:

for {
    // code for unconditional OldOp rules
    if arch == "ppc64le" {
       // code for  (OldOp x) -> (NewOp x)
    }
}

[mun...@ca.ibm.com]

Oops, I made a mistake in the generated code example, I meant something more like this:

func rewriteValuePPC64_OpPPC64OldOp {
    for {
        // code for an unconditional OldOp rule
    }

    for {

[mun...@ca.ibm.com]

Just to be clear I don't have any need for big endian ppc64, so I personally don't mind if support for it is dropped. FWIW it looks like Debian have dropped support for it in Stretch (https://lists.debian.org/debian-devel-announce/2016/10/msg00008.html).

[Michael Hudson-Doyle]

On 10 February 2017 at 07:11, <mun...@ca.ibm.com> wrote:

Just to be clear I don't have any need for big endian ppc64, so I personally don't mind if support for it is dropped. FWIW it looks like Debian have dropped support for it in Stretch (https://lists.debian.org/debian-devel-announce/2016/10/msg00008.html).

The 'powerpc' they are talking about there is 32 bit. I don't think 64-bit powerpc big-endian / ELFv1 has ever been a release architecture for Debian.

Cheers,

mwh

 

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Russ Cox]

+minux

It's nice to have a big-endian system to shake out endian-ness assumptions, but I agree that there's little point in keeping the old POWER5 support. I'm completely fine with dropping that.

Minux, I know you have a PowerMac G5 running Go, but I think you might be the only one. If that's the case, it doesn't make much sense to maintain architecture limitations for a single person.

Russ

[Quentin Smith]

I don't know if we're counting anecdata here, but I also have a PPC Mac running Linux. I haven't intentionally done any Go work on it but I wouldn't be surprised if I have some Go binaries by virtue of being included with the distro.

According to Debian's popcon, PowerPC is still as popular as armel and armhf (all three have about the same number of reports).

--Quentin

[Russ Cox]

On Fri, Feb 10, 2017 at 8:42 AM, Quentin Smith <que...@golang.org> wrote:

I don't know if we're counting anecdata here, but I also have a PPC Mac running Linux. I haven't intentionally done any Go work on it but I wouldn't be surprised if I have some Go binaries by virtue of being included with the distro.

According to Debian's popcon, PowerPC is still as popular as armel and armhf (all three have about the same number of reports).

Link?

Are you talking about 32-bit PPC or 64-bit PPC?

Russ

[Brad Fitzpatrick]

On Fri, Feb 10, 2017 at 5:54 AM, Russ Cox <r...@golang.org> wrote:

On Fri, Feb 10, 2017 at 8:42 AM, Quentin Smith <que...@golang.org> wrote:

I don't know if we're counting anecdata here, but I also have a PPC Mac running Linux. I haven't intentionally done any Go work on it but I wouldn't be surprised if I have some Go binaries by virtue of being included with the distro.

According to Debian's popcon, PowerPC is still as popular as armel and armhf (all three have about the same number of reports).

Link?

http://popcon.debian.org/

 

Are you talking about 32-bit PPC or 64-bit PPC?

Russ

[Lynn Boger]

Yeah, if we can assume power8 is the minimum for both ppc64 and ppc64le that would be great.  Then we won't have to keep adding checks to determine which code to generate or run.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Lynn Boger]

Except for endianness differences of course.

[minux]

On Thu, Feb 9, 2017 at 11:30 AM, Lynn Boger <lab...@gmail.com> wrote:

I'd like to suggest we make a change to the implementation for GOARCH ppc64 big endian.

Currently there is a requirement that ppc64 big endian remain compatible with the power5 instruction set.  Now as we plan to improve performance for ppc64le by leveraging more of the new instruction sets (power8, power9, VMX, VSX) that requires more work to maintain that power5 compatibility for ppc64 big endian.

What instructions are you talking about? I think a lot of new instructions only benefit some specialized packages, and are not suitable for compiler to generate.

In the worst case, we can split the rule files into two, and freeze the big endian one.

But as Go grows popular with ppc64le users, eventually we will have to support different subarches for ppc64le as well. Therefore just dropping ppc64 support is not the answer as we will eventually hit the same problem with ppc64le too.

[Russ Cox]

On Fri, Feb 10, 2017 at 7:45 PM, minux <mi...@golang.org> wrote:

On Thu, Feb 9, 2017 at 11:30 AM, Lynn Boger <lab...@gmail.com> wrote:

I'd like to suggest we make a change to the implementation for GOARCH ppc64 big endian.

Currently there is a requirement that ppc64 big endian remain compatible with the power5 instruction set.  Now as we plan to improve performance for ppc64le by leveraging more of the new instruction sets (power8, power9, VMX, VSX) that requires more work to maintain that power5 compatibility for ppc64 big endian.

What instructions are you talking about? I think a lot of new instructions only benefit some specialized packages, and are not suitable for compiler to generate.

In the worst case, we can split the rule files into two, and freeze the big endian one.

Why is that preferable to making the only difference between the two the endian-ness of the machine? It sounds like you are proposing that ppc64 = power5 but ppc64le can be power8+. I would much prefer not to mix processor revs with endian-ness. I believe you are the only one using ppc64 with power5 (and not even as your main machine). If that's true, we can't justify the inconsistency for less than one user.

But as Go grows popular with ppc64le users, eventually we will have to support different subarches for ppc64le as well. Therefore just dropping ppc64 support is not the answer as we will eventually hit the same problem with ppc64le too.

That is true, but defining that ppc64 = ppc64le + big-endian (with no other architecture caveats) would be a good first step.

Russ

[lab...@linux.vnet.ibm.com]

On Sunday, February 12, 2017 at 12:44:09 PM UTC-6, rsc wrote:

On Fri, Feb 10, 2017 at 7:45 PM, minux <mi...@golang.org> wrote:

On Thu, Feb 9, 2017 at 11:30 AM, Lynn Boger <lab...@gmail.com> wrote:

I'd like to suggest we make a change to the implementation for GOARCH ppc64 big endian.

Currently there is a requirement that ppc64 big endian remain compatible with the power5 instruction set.  Now as we plan to improve performance for ppc64le by leveraging more of the new instruction sets (power8, power9, VMX, VSX) that requires more work to maintain that power5 compatibility for ppc64 big endian.

What instructions are you talking about? I think a lot of new instructions only benefit some specialized packages, and are not suitable for compiler to generate.

Most of them are VMX and VSX so while most of them will be used in asm files, there could be cases where it is beneficial to be generated directly by the compiler.

I see I was not quite clear in my original request.  The request is to allow ppc64 and ppc64le to use the same instruction set, compatible with power8.  In some cases we want to use instructions that can help performance that are newer than power5 but not necessarily new in power8.

In the worst case, we can split the rule files into two, and freeze the big endian one.

If you are talking about PPC64.rules, I don't see how this helps.  Just providing separate rules files won't allow us to omit all the checks or duplicate code generation sequences that might be required.  There are many checks based on the "family" but ppc64 and ppc64le are in the same family so those are not sufficient and will require extra checks or extra code later to deal with the difference.

Why is that preferable to making the only difference between the two the endian-ness of the machine? It sounds like you are proposing that ppc64 = power5 but ppc64le can be power8+. I would much prefer not to mix processor revs with endian-ness. I believe you are the only one using ppc64 with power5 (and not even as your main machine). If that's true, we can't justify the inconsistency for less than one user.

But as Go grows popular with ppc64le users, eventually we will have to support different subarches for ppc64le as well. Therefore just dropping ppc64 support is not the answer as we will eventually hit the same problem with ppc64le too.

That is true, but defining that ppc64 = ppc64le + big-endian (with no other architecture caveats) would be a good first step.

Isn't this true for other GOARCHes too?  Within each family there could potentially be multiple target instruction sets.

Russ

[Russ Cox]

Lynn, I think you and I agree about doing this. If anyone else is interested, let's move the discussion to golang.org/issue/19074.

Thanks.

Russ