llvm dev - May 2014 - [LLVMdev] RFC: Remove AArch64 backend & rename ARM64 -> AArch64

Hi all,

Thanks to everyone's hard work over the last few months, the last
child of the AArch64/ARM64 merge issue (http://llvm.org/PR19392) has
just been resolved. So I think it's time to finish the job.

I'd like to delete the AArch64 target and move ARM64 into its place:
for now we'll accept both aarch64 and arm64 triples in all places, and
they will all be redirected to the backend residing in
lib/Target/AArch64.

This is going to be a big change, and will severely disrupt any
in-progress patches (not just the files moving, but from the
"s/ARM64/AArch64/g" we'll be doing for consistency and subsequent
clang-formatting to preserve column count). So I'd like to make sure
that these disruptions are kept to a minimum. Currently, the patches I
know about are:

+ Bradley is working on basic-a64-diagnostics.s. I propose to wait
until this is finished before moving.
+ I've got 1 or 2 things going on, I can work around those easily enough.
+ James has discovered the joys big-endian interactions with ACLE.
Fortunately this appears to be mostly Clang-based, so shouldn't affect
things much.
+ Dave is working on improving the A53 scheduler model. I'll wait
until that's committed.

So, does anyone have extra work they'd like to get in first, or any
other problems with the current state of the ARM64 backend that they
think should block this?

If not, I'd suggest I start work either next weekend (if I'm feeling
keen, to minimize disruption) or on Monday 26th (if not). I expect it
to take a day or so to disentangle things; but after the move commit
(while I'm doing final tidying up of tests & such), work should be
able to start again without issue.

Looks like we might make 3.5 comfortably!

Cheers.

Tim.

(Oh, and I'm away this weekend and early next week; without any net
for the weekend bit, so don't worry if it takes me a while to reply).

On 16 May 2014 12:19, Tim Northover <t.p.northover at gmail.com>
wrote:
> So, does anyone have extra work they'd like to get in first, or any
> other problems with the current state of the ARM64 backend that they
> think should block this?
Hi Tim,

Now is as good as any time, and will give us plenty of time to
stabilise for 3.5.

Now, the practical side of it... what's the schedule for the movement
regarding Clang vs. LLVM vs. others?

Are we going to have a global code freeze until all projects have
moved their sources and test cases? Or are we doing it one project at
a time, likely breaking the hell out of everything else, but still
being able to accept patches to the old structure to non-migrated
sub-projects, before the final movement? Both are extremely
disruptive, but I think goes down to personal preference to whomever
is doing the merge.

cheers,
--renato

Hey Tim,

The new Cortex-A53 sched model has been submitted (r209001). BTW, Hai 
Lui found a bug with post-incremented vector loads for Cortex-A53 
(http://llvm.org/bugs/show_bug.cgi?id=19761). The bug is is there with 
the previous basic sched model as well as this new one. I'm working on a 
fix that should make it up for review later. I just wanted to bring it 
up in case you want to pick that one up before the switchover too.

Thanks...
-Dave

On 05/16/2014 07:19 AM, Tim Northover wrote:
> Hi all,
>
> Thanks to everyone's hard work over the last few months, the last
> child of the AArch64/ARM64 merge issue (http://llvm.org/PR19392) has
> just been resolved. So I think it's time to finish the job.
>
> I'd like to delete the AArch64 target and move ARM64 into its place:
> for now we'll accept both aarch64 and arm64 triples in all places, and
> they will all be redirected to the backend residing in
> lib/Target/AArch64.
>
> This is going to be a big change, and will severely disrupt any
> in-progress patches (not just the files moving, but from the
> "s/ARM64/AArch64/g" we'll be doing for consistency and
subsequent
> clang-formatting to preserve column count). So I'd like to make sure
> that these disruptions are kept to a minimum. Currently, the patches I
> know about are:
>
> + Bradley is working on basic-a64-diagnostics.s. I propose to wait
> until this is finished before moving.
> + I've got 1 or 2 things going on, I can work around those easily
enough.
> + James has discovered the joys big-endian interactions with ACLE.
> Fortunately this appears to be mostly Clang-based, so shouldn't affect
> things much.
> + Dave is working on improving the A53 scheduler model. I'll wait
> until that's committed.
>
> So, does anyone have extra work they'd like to get in first, or any
> other problems with the current state of the ARM64 backend that they
> think should block this?
>
> If not, I'd suggest I start work either next weekend (if I'm
feeling
> keen, to minimize disruption) or on Monday 26th (if not). I expect it
> to take a day or so to disentangle things; but after the move commit
> (while I'm doing final tidying up of tests & such), work should be
> able to start again without issue.
>
> Looks like we might make 3.5 comfortably!
>
> Cheers.
>
> Tim.
>
> (Oh, and I'm away this weekend and early next week; without any net
> for the weekend bit, so don't worry if it takes me a while to reply).
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140516/629de7e1/attachment.html>

Hi Renato,
> Now, the practical side of it... what's the schedule for the movement
> regarding Clang vs. LLVM vs. others?
>
> Are we going to have a global code freeze until all projects have
> moved their sources and test cases?
I'll probably be building LLVM, Clang & lldb during the process, and
commit the fundamentals at the same time. After that, cleanups will
continue for a while but shouldn't block any other commits. Since most
external interfaces will remain the same though, I'm not anticipating
many synchronisation issues.

So, since no-one has told me the sky would fall down if I do this, I'm
planning to go ahead. Last chance to call a halt, everyone!

Cheers.

Tim.