llvm dev - Mar 2014 - [LLVMdev] Contributing the Apple ARM64 compiler backend

Hi,

Apart from whether fast-isel should be enabled or disabled (I think enabled,
personally), I haven't heard any dissenting voices about how to attack the
merge problem yet.

Tim, am I correct in saying that you believe AArch64 -> ARM64 is the right
way to go?

Does anyone disagree with that approach?

Cheers,

James
________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf
Of Eric Christopher [echristo at gmail.com]
Sent: 31 March 2014 21:28
To: JF Bastien
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend

On Mon, Mar 31, 2014 at 1:23 PM, JF Bastien <jfb at google.com>
wrote:
> On Mon, Mar 31, 2014 at 1:01 PM, Renato Golin <renato.golin at
linaro.org>
> wrote:
>>
>> On 31 March 2014 20:55, Tim Northover <t.p.northover at
gmail.com> wrote:
>> > I'd almost prefer to leave it in for the bugs to be discovered
>> > (perhaps after some simple tests of our own). ARM went wirthout
>> > FastISel support on Linux for years simply because it was declared
>> > Darwin-only.
>>
>> Given the unique opportunity we have now, I'd say we should at
least
>> give it a try.
>
>
> I'm not sure I understand what you're proposing: check in with
FastISel
> turned on for Linux, or off? I'd be afraid of bitrot if it's off,
which was
> the main issue on the ARM side because code got added assuming Linux would
> work the same. Does it pass the tests on Linux with FastISel, or do we at
> least understand what's missing?
I think we're assuming it's turned on in ToT. And I haven't done any
testing of the generated code for fast isel.

-eric
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2548782

On Mon, Mar 31, 2014 at 1:40 PM, James Molloy <James.Molloy at arm.com>
wrote:
> Hi,
>
> Apart from whether fast-isel should be enabled or disabled (I think
enabled, personally), I haven't heard any dissenting voices about how to
attack the merge problem yet.
>
> Tim, am I correct in saying that you believe AArch64 -> ARM64 is the
right way to go?
>
> Does anyone disagree with that approach?
I, too, believe this.

-eric
>
> Cheers,
>
> James
> ________________________________________
> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eric Christopher [echristo at gmail.com]
> Sent: 31 March 2014 21:28
> To: JF Bastien
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend
>
> On Mon, Mar 31, 2014 at 1:23 PM, JF Bastien <jfb at google.com>
wrote:
>> On Mon, Mar 31, 2014 at 1:01 PM, Renato Golin <renato.golin at
linaro.org>
>> wrote:
>>>
>>> On 31 March 2014 20:55, Tim Northover <t.p.northover at
gmail.com> wrote:
>>> > I'd almost prefer to leave it in for the bugs to be
discovered
>>> > (perhaps after some simple tests of our own). ARM went
wirthout
>>> > FastISel support on Linux for years simply because it was
declared
>>> > Darwin-only.
>>>
>>> Given the unique opportunity we have now, I'd say we should at
least
>>> give it a try.
>>
>>
>> I'm not sure I understand what you're proposing: check in with
FastISel
>> turned on for Linux, or off? I'd be afraid of bitrot if it's
off, which was
>> the main issue on the ARM side because code got added assuming Linux
would
>> work the same. Does it pass the tests on Linux with FastISel, or do we
at
>> least understand what's missing?
>
> I think we're assuming it's turned on in ToT. And I haven't
done any
> testing of the generated code for fast isel.
>
> -eric
>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2548782
>

On 31 Mar 2014 21:50, "Eric Christopher" <echristo at gmail.com>
wrote:
> > Tim, am I correct in saying that you believe AArch64 -> ARM64 is
the
right way to go?
> >
> > Does anyone disagree with that approach?
>
> I, too, believe this.
+1

Cheers,
Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140331/d8986729/attachment.html>

Hi James,
> Tim, am I correct in saying that you believe AArch64 -> ARM64 is the
right way to go?
I think so, on the whole. I agree with your assessment that porting
performance improvements will be harder than porting correctness.

I also think we've made a few mistakes with the AArch64 backend that I
hope we'll be able to avoid in the merged version:

+ My load/store pattern idea has turned out to be a maintenance
nightmare. OK, it proves that TableGen *can* do the job, but I think
the C++ used in other targets is substantially clearer.
+ I don't think the v1iN approach to SISD operations has turned out
well. There's been far too much boiler-plate added to handle
operations that are essentially identical. In ARM64 there's the
beginnings of a MachineFunction pass to do the work of selecting SISD
instructions (ARM64AdvSIMDScalarPass.cpp). I'm hoping that will prove
cleaner in the end.
+ Sharing the @llvm.arm.neon space turned out rather more confusing
than I'd hoped. So many exceptions that the Clang benefits weren't
realised, but so much overlap that you never knew which intrinsic
would apply. It's also rather a layering violation.

On the other hand, it's been a while since I first saw ARM64 and I
know there were quite a few WTF moments when I did. I've been trying
to "improve" things since then, but some issues remain. The ones I can
remember are:

+ Instruction names are often inconsistent, particularly in the NEON
space. Sometimes v2i32, sometimes v2f32. Sometimes v2i32 takes that as
an arg, others it returns that, ... (I also think "vXiY" is unwieldy
and prefer "4s" etc, though that's personal).
+ Aliases seem more ad-hoc, with some fairly nasty hackery in
AsmParser and InstPrinter compared to AArch64.

I'd *really* love to hear any other people's WTFs (with either). Even
if we go with ARM64, they're issues that will soon become "that's
just
how it's done" but right now we have an opportunity to remember them,
and hopefully fix them.

Cheers.

Tim.

I would like to see comparative performance on cortex A53 and A57 before
commenting. I hope to have this for discussion at the hackers lab at EuroLLVM.

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of James Molloy
Sent: Monday, March 31, 2014 1:40 PM
To: Eric Christopher; JF Bastien
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend

Hi,

Apart from whether fast-isel should be enabled or disabled (I think enabled,
personally), I haven't heard any dissenting voices about how to attack the
merge problem yet.

Tim, am I correct in saying that you believe AArch64 -> ARM64 is the right
way to go?

Does anyone disagree with that approach?

Cheers,

James
________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf
Of Eric Christopher [echristo at gmail.com]
Sent: 31 March 2014 21:28
To: JF Bastien
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend

On Mon, Mar 31, 2014 at 1:23 PM, JF Bastien <jfb at google.com>
wrote:
> On Mon, Mar 31, 2014 at 1:01 PM, Renato Golin 
> <renato.golin at linaro.org>
> wrote:
>>
>> On 31 March 2014 20:55, Tim Northover <t.p.northover at
gmail.com> wrote:
>> > I'd almost prefer to leave it in for the bugs to be discovered
>> > (perhaps after some simple tests of our own). ARM went wirthout 
>> > FastISel support on Linux for years simply because it was declared
>> > Darwin-only.
>>
>> Given the unique opportunity we have now, I'd say we should at
least
>> give it a try.
>
>
> I'm not sure I understand what you're proposing: check in with 
> FastISel turned on for Linux, or off? I'd be afraid of bitrot if
it's
> off, which was the main issue on the ARM side because code got added 
> assuming Linux would work the same. Does it pass the tests on Linux 
> with FastISel, or do we at least understand what's missing?
I think we're assuming it's turned on in ToT. And I haven't done any
testing of the generated code for fast isel.

-eric
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office
110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company
No:  2548782


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Mon, Mar 31, 2014 at 2:11 PM, Kipping, David
<dkipping at qti.qualcomm.com> wrote:
> I would like to see comparative performance on cortex A53 and A57 before
commenting. I hope to have this for discussion at the hackers lab at EuroLLVM.
>
Are you have running numbers on A53 and A57? Will you post them after?
Have you done tuning of the AArch64 port on these processors?

Any discussion of which port to use as the base should definitely take
place on the mailing list.

-eric
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On Behalf Of James Molloy
> Sent: Monday, March 31, 2014 1:40 PM
> To: Eric Christopher; JF Bastien
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend
>
> Hi,
>
> Apart from whether fast-isel should be enabled or disabled (I think
enabled, personally), I haven't heard any dissenting voices about how to
attack the merge problem yet.
>
> Tim, am I correct in saying that you believe AArch64 -> ARM64 is the
right way to go?
>
> Does anyone disagree with that approach?
>
> Cheers,
>
> James
> ________________________________________
> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eric Christopher [echristo at gmail.com]
> Sent: 31 March 2014 21:28
> To: JF Bastien
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Contributing the Apple ARM64 compiler backend
>
> On Mon, Mar 31, 2014 at 1:23 PM, JF Bastien <jfb at google.com>
wrote:
>> On Mon, Mar 31, 2014 at 1:01 PM, Renato Golin
>> <renato.golin at linaro.org>
>> wrote:
>>>
>>> On 31 March 2014 20:55, Tim Northover <t.p.northover at
gmail.com> wrote:
>>> > I'd almost prefer to leave it in for the bugs to be
discovered
>>> > (perhaps after some simple tests of our own). ARM went
wirthout
>>> > FastISel support on Linux for years simply because it was
declared
>>> > Darwin-only.
>>>
>>> Given the unique opportunity we have now, I'd say we should at
least
>>> give it a try.
>>
>>
>> I'm not sure I understand what you're proposing: check in with
>> FastISel turned on for Linux, or off? I'd be afraid of bitrot if
it's
>> off, which was the main issue on the ARM side because code got added
>> assuming Linux would work the same. Does it pass the tests on Linux
>> with FastISel, or do we at least understand what's missing?
>
> I think we're assuming it's turned on in ToT. And I haven't
done any testing of the generated code for fast isel.
>
> -eric
>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England
& Wales, Company No:  2548782
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev