[llvm-dev] [RFC] Removing PowerPC/Darwin Support?

[Iain Sandoe via llvm-dev]

Hi Hal, folks,

> On 22 Oct 2016, at 18:31, Chris Lattner <clattner at apple.com> wrote:
> 
> On Oct 20, 2016, at 6:57 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote:

>> I don't believe that anyone is currently using (a recent) LLVM on PowerPC/Darwin.

My current work-in-progress is on 3.8.1 and 3.9.0; following trunk is just too hard for reasons that will probably be evident from the comments below.

I promise to post as clean a version as I can muster to github before the SJ conference (there’s no way most of it’s going to be polished enough to post for review).

>> As far as I know, Apple stopped supporting PowerPC hardware years ago.

… and, as such, it’s agreed that there’s no commercial justification for supporting it .. but some of us still have several happily working machines (alongside our x86 boxen).

A small point in favour: I will note in passing that powerpc-darwin (certainly on GCC) has habit of exploring ‘corners’ and highlighting bugs that went un-noticed elsewhere.  It would seem that there is some merit in diversity of back-ends in this respect.

>> There is a significant amount of code in the PowerPC backend dedicated to Darwin support and removing it would make maintaining the rest of the backend easier. 

I had already spoken with Kit we’d agreed to sit down in SJ and discuss the patch set and how to make things easier for all of us (there are at least a few of the patches that benefit other parts of the port).

If you and Eric could spare 30mins, perhaps we could come up with a list of things that are made ‘difficult’ by the port and perhaps give me some time to address them?

(for example partitioning out the Darwin portions)?

>> If anyone expects upcoming LLVM releases to continue to support PowerPC/Darwin, please speak up.

I would be sad to see it go, despite that it’s purely an enthusiast’s hobby thing (and it’s not possible to guarantee any particular schedule as such).

> Wow, end of an era.  No concerns from me: someone who cares about building software for old Darwin/PPC machines can use an older version of LLVM.

unfortunately, this is _not_ the case (and is the underlying reason that supporting it is hard).

The in-tree powerpc-darwin port is incomplete;  there are significant chunks of the ABI un-implemented; 
in some respects it’s self-consistent, but it won’t interwork with the system ABI for anything other than simple cases.

To make life more interesting, actual system ABI is not fully documented, so one has to deduce it from “see what gcc-4.x does” (this is, shall we say, time-consuming - especially as a hobby activity!!).

However, as of 3.8.0 I have got a pretty solid ABI cover with some wrinkles on bitfields with __attribute__((…));  I strongly suspect some of those wrinkles affect other ports too (but still working through them).

So … right now it’s not a matter of someone maintaining a working in-tree port (my colleague Jon has a box he’s willing to use as a build-bot once we get to the stage of working trunk).  Rather it’s a matter of trying to finish off a port on hobby time, against a moving target - which is slow work.

It’s agreed there’s no commercial justification (other than the diversity argument) for keeping it - but I would rather see an engineering solution that solved the maintenance difficulties, instead of just deleting it.

If I’m the lone voice, then fair enough :-) … 
…  however, I’d be very sad to see the assembler go - I was hoping to use it replace the cctools as (to give access to .cfi_xxxx on ppc to other tools) and for use in wider contexts.

cheers
Iain