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 <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
