[cfe-commits] [llvm-commits] The AArch64 LLVM (& Clang) target

[Sean Silva]

This is awesome! What kinds of code have you compiled with it?

Some small "peephole" comments about the patches:

+static TypedefDecl *
+CreateAArch64ABIBuiltinVaListDecl(const ASTContext *Context) {

You are creating new types in here, which modifies the ASTContext, so
it's not really correct to take it as const (as evidenced by the uses
of const_cast's in this function).

+  if (FreeRegs >= RegsNeeded) {
+    FreeRegs -= RegsNeeded;
+    return ABIArgInfo::getDirect(DirectTy);
+  } else {
+    llvm::Type *Padding = 0;

<http://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return>.

+  bool BigStack =
+    (RS && estimateStackSize(MF) >= TII.estimateRSStackLimit(MF))
+    || MFI->hasVarSizedObjects() // Access will be from X29: messes things up
+    || (MFI->adjustsStack() && !hasReservedCallFrame(MF));
+
+  if (BigStack) {
+    // We certainly need some slack space for the scavenger, preferably an
+    // extra register.

This can be simplified with an early exit
<http://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code>

+void AArch64MCExpr::PrintImpl(raw_ostream &OS) const {
+  switch (Kind) {
+  default: assert(0 && "Invalid kind!");

+  case MCExpr::Target:
+    assert(0 && "Can't handle nested target expr!");

use llvm_unreachable()

-- Sean Silva

On Mon, Jan 7, 2013 at 7:57 AM, Tim Northover <Tim.Northover at arm.com> wrote:
> Hi all,
>
> I now finally have permission to start upstreaming the long-delayed backend
> for
> ARM's new 64-bit architecture, AArch64.
>
> In summary, we're proposing this backend for inclusion into LLVM; first as an
> experimental target, but with a view to being fully supported as soon as
> possible.
>
> Splitting up an entire target into smaller patches is rather tricky, but I've
> isolated all changes to generic LLVM code. I'll be sending those patches out
> for individual review and wouldn't consider committing until all that's left
> in the backend patch is very definitely AArch64 specific. Let me know if
> there's anything else I can do to help.
>
> Meanwhile, the patch attached here *does* contain those generic changes, which
> should probably be ignored for review purposes. They're present so that
> someone curious can simply apply a single patch and get a working backend.
>
> The current status of the backend is roughly as follows:
>   + In a large scale: C99 and C++03 code targeting ELF on Linux should be
>     supported. Problems there will be a high priority and are probably unknown
>     to us.
>   + Initial support for using NEON instructions is underway, being implemented
>     by Ana Pazos from Qualcomm (thanks!). This is not complete though and
>     should not be expected to work for generic code yet.
>   + The backend produces mostly unoptimised code. Work has been mainly on
>     features, with the lack of hardware making more detailed performance
>     analysis less useful at present.
>   + DWARF debugging should be supported.
>   + Position-independent code should be supported.
>   + Thread-local storage (GNU, rather than C++11) should be supported.
>   + Inline assembly should be supported.
>   + There is no MCJIT (or any other JIT) support.
>   + Only one memory model is supported: code and statically allocated data
>     must occupy a contiguous 4GB space (a.k.a. "large").
>
> There are some areas known to need refactoring, but where we refrained to
> avoid large merge conflicts. I would prefer the nastiest of these to be
> delayed and form part of the Experimental -> Stable target transition, where
> merges will hopefully be less painful. Most notably the ConstantIslandPass
> should probably be shared between AArch32 and AArch64.
>
> If there's anything we can do to make this process easier for people, please
> let me know (a branch in svn? Upload patch to phabricator? ...). Similarly,
> any other questions or comments would be welcome.
>
> Cheers.
>
> Tim.
>
> -- 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.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>