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

Hi everyone,

I don't believe that anyone is currently using (a recent) LLVM on
PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC hardware
years ago. 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. If anyone expects upcoming LLVM releases to continue to
support PowerPC/Darwin, please speak up.

Thanks again,
Hal 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

+1.

-eric

On Thu, Oct 20, 2016 at 4:57 PM Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi everyone,
>
> I don't believe that anyone is currently using (a recent) LLVM on
> PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC hardware
> years ago. 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. If anyone expects upcoming LLVM releases to continue
> to support PowerPC/Darwin, please speak up.
>
> Thanks again,
> Hal
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161020/72b328d9/attachment.html>

The only part I'd like to see *NOT* removed is the darwin PPC asm format.
Not because I care about ppc/darwin, but because that format is like 1000x
easier to read -- especially for those of us who aren't PPC experts -- than
the insane standard PPC assembly format. :)

On Thu, Oct 20, 2016 at 7:57 PM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi everyone,
>
> I don't believe that anyone is currently using (a recent) LLVM on
> PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC hardware
> years ago. 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. If anyone expects upcoming LLVM releases to continue
> to support PowerPC/Darwin, please speak up.
>
> Thanks again,
> Hal
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161021/f723e1ab/attachment.html>

Hi James,

I agree, we should keep a mode that prints register names (instead of just the
numbers). I lean toward having a verbose mode that is compatible with the GNU
assembler, which means %r1 instead of just r1. gas will also accept that syntax,
so it seems more useful than the Darwin syntax on current systems. What do you
think?

 -Hal

----- Original Message -----
> From: "James Y Knight" <jyknight at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Ehsan A
Amiri" <amehsan at ca.ibm.com>, "Iain Sandoe" <iain at
codesourcery.com>
> Sent: Friday, October 21, 2016 10:37:44 AM
> Subject: Re: [llvm-dev] [RFC] Removing PowerPC/Darwin Support?
> 
> 
> The only part I'd like to see *NOT* removed is the darwin PPC asm
> format. Not because I care about ppc/darwin, but because that format
> is like 1000x easier to read -- especially for those of us who
> aren't PPC experts -- than the insane standard PPC assembly format.
> :)
> 
> 
> On Thu, Oct 20, 2016 at 7:57 PM, Hal Finkel via llvm-dev <
> llvm-dev at lists.llvm.org > wrote:
> 
> 
> Hi everyone,
> 
> I don't believe that anyone is currently using (a recent) LLVM on
> PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC
> hardware years ago. 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. If anyone expects
> upcoming LLVM releases to continue to support PowerPC/Darwin, please
> speak up.
> 
> Thanks again,
> Hal
> 
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

On Oct 20, 2016, at 6:57 PM, Hal Finkel via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Hi everyone,
> 
> I don't believe that anyone is currently using (a recent) LLVM on
PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC hardware
years ago. 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. If anyone expects upcoming LLVM releases to continue to
support PowerPC/Darwin, please speak up.
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.

-Chris

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