[LLVMbugs] [Bug 19850] New: AArch64 cannot self-host on ELF targets (ABI for bool is dodgy)

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19850

            Bug ID: 19850
           Summary: AArch64 cannot self-host on ELF targets (ABI for bool
                    is dodgy)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: unassignedbugs at nondot.org
          Reporter: t.p.northover at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The AArch64 (née ARM64) backend fails many tests when self-hosting at -O0. The
issue appears to be over who takes responsibility for extending bool types and
by how much.

The AAPCS could really do with a clarification note here, but my interpretation
is that (unlike all other types), the *caller* should extend it to 1 byte (i.e.
ensure that the low byte is either 0 or 1). The callee is responsible for any
junk in the higher bits (as with i8, i16 and small structs).

On Darwin, of course, the caller needs to extend to the full 32-bits, as with
other types.

Looking at the LangRef, I think this means two things need to happen:

1. Preferably Clang should mark i1 arguments as "zeroext", so that LLVM makes
sure the caller does so "to the extent required by the target’s ABI"
(tautological as that is). Both ABIs do require extension of some kind for this
type.

2. LLVM needs to mark i1 arguments as extended to i8 on Linux, to i32 on
Darwin.

There's some highly suspect code in LowerFormalArguments that looks like it may
have been intended to deal with something like this but *never* triggers
because of a miscommunication with AArch64CallingConv.h. The actual extension
on Darwin platforms is taken care of by SelectionDAGBuilder.cpp.

I'll need to come up with a way to repurpose that code as neatly as possible.
Currently it wants to produce a "CopyFromReg -> AssertZExt(i1) -> Trunc(i1)",
but that wouldn't represent the AAPCS situation even if it did trigger (the
AssertZExt node would extend to the full i32). We might want "CopyFromReg ->
Trunc(i8) -> AssertZExt(i1)" instead, but I need to think.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140525/901de121/attachment.html>