Jack Andersen authored Dec 30, 2021 and Silviu Baranga committed Jan 23, 2023

Extends response file expansion to recognize `<CFGDIR>` and expand to the
current file's directory. This makes it much easier to author clang config
files rooted in portable, potentially not-installed SDK directories.

A typical use case may be something like the following:

```
--target=sample
-isystem <CFGDIR>/include
-L <CFGDIR>/lib
-T <CFGDIR>/ldscripts/link.ld
```

Reviewed By: sepavloff

Differential Revision: https://reviews.llvm.org/D115604

When NEON is disabled, we were up using non-C64 loads/stores for the COPY.
Fix this by updating AArch64InstrInfo::copyPhysReg().

When NEON is disabled, we end up using non-C64 loads/stores for the COPY.

We shedule instructions slightly differently with the current Morello LLVM.

Akshay Kumar authored Jan 17, 2022 and Alex Richardson committed Jan 20, 2023

For the following test case, clang is crashing for ARM64 architecture
$ cat crash.c
double crash(double a, double b)
{
	return __builtin_copysign(a, b);
}

$ clang -O2 -march=armv8-a+nosimd --target=arm64 -S crash.c -o /dev/null
fatal error: error in backend: Cannot select: 0x7fae361bb4e8: v2i64 = AArch64ISD::BIT 0x7fae361bb210, 0x7fae361bb278, 0x7fae361bb480
Fix: PR51806

Reviewed By: dmgreen

Differential Revision: https://reviews.llvm.org/D116581

(cherry picked from commit 6f61fe7de97c78adc8fac528239260122fb83be5)

Alex Richardson authored May 12, 2022 and Alex Richardson committed Jan 20, 2023

I was trying to compile code with -march=+nosimd and hit various
instruction predicate verification errors, this patch should address the
ones I saw in integer to floating-pointer conversions.

I noticed that for signed conversions, some non-NEON instruction sequences
are shorter. I don't know if the longer one is still faster on current
architectures (the patterns date back to the initial backend import)

Reviewed By: dmgreen

Differential Revision: https://reviews.llvm.org/D125308

(cherry picked from commit 09551251e32a0a00486c3de5e29b8df0aa4e5540)

Alex Richardson authored May 12, 2022 and Alex Richardson committed Jan 20, 2023

Differential Revision: https://reviews.llvm.org/D125240

(cherry picked from commit f8639133b58dd7335474dfa9dbb04b13098c5294)

Alex Richardson authored Apr 12, 2022 and Alex Richardson committed Jan 20, 2023

I was trying to compile with -march=+nosimd and hit the following assertion:
`Attempting to emit FABD64 instruction but the Feature_HasNEON predicate(s) are not met`.
This adds a HasNEON predicate to the patterns which was omitted in commit
21d9b33d for some reason.
The new code generation matches GCC with -mcpu=<cpu>+nosimd:
https://godbolt.org/z/n1Y7xh5jo

Differential Revision: https://reviews.llvm.org/D123491

(cherry picked from commit ee44896cf42d3360f7e0229c360258c92262a47b)

Alex Richardson authored Apr 11, 2022 and Alex Richardson committed Jan 20, 2023

(cherry picked from commit 32a353a5e08628403422a1f71e6500bc1f68e8fb)

Check OpsAndLoops instead of Loops to find out the number
of operands of the expression. This was causing an issue
where we weren't doing the usual base/offset expansion.

Additionally fix the logic in expandAddToGEP for capabilities.
Just emit the ugly GEP to avoid the case where we would need
multiple GEPs.

Fixes #65

defaulting to c30.

Fixes #63

This is due to tightening of capability permissions returned by mmap.

We should end up with a permissions fault everywhere, however
at the moment the exact type of fault that we get depends on
the environment. For now match all faults.

Alex Richardson authored Dec 09, 2022 and Silviu Baranga committed Dec 12, 2022

This does not make sense with opaque pointers, and also caused issues for
CHERI/Morello where hardcoding address-space zero prevented optimization.

Downstream change: !180

Co-authored-by: Silviu Baranga <silviu.baranga@arm.com>

Reviewed By: lebedev.ri

Differential Revision: https://reviews.llvm.org/D139708

Zequan Wu authored Jul 20, 2022 and Graeme Jenkinson committed Nov 22, 2022

[SemaCXX] Set promotion type for enum if its type is promotable to integer type even if it has no definition.

EnumDecl's promotion type is set either to the parsed type or calculated type
after completing its definition. When it's bool type and has no definition,
its promotion type is bool which is not allowed by clang.

Fixes #56560.

Differential Revision: https://reviews.llvm.org/D130210

(cherry picked from commit d870a575631d2cedab2ff237af8edd17916edc64)

The issue was that we were using the A64 load/store opcodes in C64.
We only have a reproducer for one instance (STPXi) but I've managed
to spot several more. This is attempting to fix all instances.

On Rainier, PCC bounds are not predicted, and only readable by ADR(P)
once the branch has been resolved. This means that, if a jump table is
in a tight loop, the backend fills up with ADR->BR->ADR->BR->... chains
that result in large numbers of backend stalls. In particular, the state
machine benchmark in CoreMark hits this, resulting in a 15% overhead
(cycles) and around 3x the backend stalls that account for almost all
this overhead. Using indirect integer branches, whilst sad that it has
to be done to achieve competitive performance, should be just as safe,
and reduces CoreMark's overhead to around 1% more cycles.

When parsing bitcode files, ld.lld would previously hit an assertion due to
a mismatched DataLayout. This patch adds minimal support for Morello LTO
by inferring the target ABI from the morello-c64-plt flag. This flag
is set automatically based on the ELF e_flags, so as long as the first
input file is a purecap file, it should also work automatically when using
a bare ld.lld invocation instead calling ld.lld via clang.

This is lightly tested, but I have been able to build various projects
with -flto=thin.

it use scbnds instead of scbndse (in hybrid we're not
guaranteed that the capability would be representable).

Tom Stellard authored Jul 28, 2021 and Silviu Baranga committed Oct 03, 2022

This function is marked with CINDEX_LINKAGE, but was never added to the
export list / linker script.

Reviewed By: jrtc27

Differential Revision: https://reviews.llvm.org/D106974

(cherry picked from commit a4edb2b1ba0bda9042e87ca3f3e1b9f70598df9a)

Richard Smith authored Feb 02, 2022 and Silviu Baranga committed Oct 03, 2022

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

(cherry picked from commit 30baa5d2a450d5e302d8cba3fc7a26a59d4b7ae1)

Adrian Prantl authored Dec 10, 2021 and Silviu Baranga committed Oct 03, 2022

DwarfExpression::addUnsignedConstant(const APInt &Value) only supports
wider-than-64-bit values when it is used to emit a top-level DWARF
expression representing the location of a variable. Before this change,
it was possible to call addUnsignedConstant on >64 bit values within a
subexpression when substituting DW_OP_LLVM_arg values.

This can trigger an assertion failure (e.g. PR52584, PR52333) when it
happens in a fragment (DW_OP_LLVM_fragment) expression, as
addUnsignedConstant on >64 bit values splits the constant into separate
DW_OP_pieces, which modifies DwarfExpression::OffsetInBits.

This change papers over the assertion errors by bailing on overly wide
DW_OP_LLVM_arg values. A more comprehensive fix might be to be to split
wide values into pointer-sized fragments.

[0] https://github.com/llvm/llvm-project/blob/e71fa03/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L799-L805

Patch by Ricky Zhou!

Differential Revision: https://reviews.llvm.org/D115343

(cherry picked from commit c7c84b90879f0252c58894f70d2a19fc4c01cf64)

Richard Smith authored Mar 31, 2022 and Silviu Baranga committed Oct 03, 2022

lexically contains a mention of the pack.

Systematically distinguish between syntactic and semantic references to
packs, especially when propagating dependence from a type into an
expression. We should consult the type-as-written when computing
syntactic dependence and should consult the semantic type when computing
semantic dependence.

Fixes #54402.

(cherry picked from commit f1b0a4fc540f986372f09768c325d505b75b414d)

We need the size of the capability to match exactly the size of the
memory transfer to do this.

For any representable length of the form (1 << 12) - 1) << (E + 3), i.e.
the largest representable length for an exponent E, RRLEN and RRMASK as
defined in Morello will incorrectly round the length up to the next
representable one. On the surface this might not be an issue, as one
might imagine it just results in a bit of redundant padding in edge
cases, but it is in fact problematic for software written against the
generic CHERI C interfaces. For example, a common way to assert that a
length is representable is cheri_representable_length(x) == x, which is
used in various places in CheriBSD, but this fails in the case that x is
one of the special values. In particular, this has been seen to happen
in the CheriBSD kernel's ELF image activator, since we round and align
the start and end addresses for the mapped region to be representable
and later assert this has been done, but very occasionally executables
are produced that trip this up and panic the kernel. One could go add a
workaround to every piece of software that requires the intrinsics to be
exact, but this quickly becomes tedious and may not catch all such
cases, leaving latent hard-to-trigger bugs on just Morello.

Instead, make the Morello implementation of the intrinsics conform to
the CHERI contract by expanding them to a multi-instruction sequence
that detects potentially-problematic cases and fixes them to be what
they should be. For efficiency, however, we leave DYNAMIC_STACKALLOC as
padded more than needed; note that we already have a second SCBNDS for
this case that takes the original unpadded length and so we will still
get the tighter bounds on the capability, just a bit of padding after
the top.

For now the inexact LLVM intrinsics are not made available to Clang, but
these should be added once a suitable name has been agreed upon (such as
__builtin_morello_*_inexact to match the LLVM names chosen here, which
should not be considered stable).

Distinguish between purecap and hybrid based on the existence of the
EF_AARCH64_CHERI_PURECAP flag in the binary. This information is passed
into the ArchSpec and used when determining the size of a pointer. Note
that even with this patch we still don't have a fully consistent
handling of pointers vs addresses in lldb, so certain things might still
be broken. However, we can now enable one of the end-to-end tests for
hybrid mode. It used to pass only for purecap because we were making an
assumption about certain pointers being capabilities.

* Trim potential trailing / on the input ANDROID_OUT

branches

We now generate the expected relocation for a function instead of a
relocation against section+offset. This ensures that compiling with
-ffunction-sections no longer creates relocations without the LSB set.

Alex Richardson authored Aug 25, 2022 and Alex Richardson committed Aug 26, 2022

While this does not matter for most targets, when building for Arm Morello,
we have to mark the symbol as a function and add size information, so that
LLD can correctly evaluate relocations against the local symbol.
Since Morello is an out-of-tree target, I tried to reproduce this with
in-tree backends and with the previous reviews applied this results in
a noticeable difference when targeting Thumb.

Background: Morello uses a method similar Thumb where the encoding mode is
specified in the LSB of the symbol. If we don't mark the target as a
function, the relocation will not have the LSB set and calls will end up
using the wrong encoding mode (which will almost certainly crash).

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D131429

(cherry picked from commit 0483b008759b566984f040269b7a90210922a145)

When calling a dso_local function, we end up creating a call against the
.Lfoo$local label. This might be converted to a relocation against a
section if there is such a matching one (which is a lot more likely with
-ffunction-sections). LLD will later infer that a C64->A64 thunk is needed
and generate an incorrect binary.

Markus Böck authored Jan 06, 2022 and Silviu Baranga committed Aug 17, 2022

-Wdeclaration-after-statement currently only outputs an diagnostic if the user is compiling in C versions older than C99, even if the warning was explicitly requested by the user.
This patch makes the warning also available in later C versions. If the C version is C99 or later it is simply a normal warning that is disabled by default (as it is valid C99) and has to be enabled by users. In older versions it remains an extension warning, and therefore affected by -pedantic.

The above behaviour also matches GCCs behaviour.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51931

Differential Revision: https://reviews.llvm.org/D114787

https://reviews.llvm.org/D114787

using a pseudoinst.

This guarantees that MachineLICM can't hoist the adrp
and not the ldr.

We were doing this at ISel which is way too early as
it can interfere with MachineLICM. Additionally
this adds an add instruction which is not always a win.

addresses for aliases in purecap.

The motivation is that the global merge pass will replace
globals with aliases to a merged global.

The merged global address is produced by loading a capability
from a pc-relative relocation (same as before).

Safe loads/stores can use the merged global directly. Unsafe
uses still need to produce the address of the global by doing
a load from the capability table.

For now this just does the merging, and for purecap we're
replacing the old globals with the new aliases. This doesn't
change codegen (we're still acccessing globals via loads),
but it will enable future optimizations.

Some notable changes to the globals merge pass:
  - We're attempting to pad globals to make capabilies to the
    emitted aliases representable. This doesn't do anything,
    since the maximum size of the merged global is 4096, but
    it's nice to have this in place.
  - We're replacing the old globals with aliases to the merged
    global. This keeps size information and we can consume it
    in future optimizations.
  - For purecap we merge BSS globals with non-BSS ones, which
    means globals that were in .bss now end up in .data. For
    purecap this is worth it as it's going to remove some
    loads/stores

AArch64SandboxGlobalsOpt also now processes aliases as well.
The metadata format for determining the index of the capability
table for a global has changed since global aliases cannot
attach metadata.

Sometimes the binaries might get left behind from a previous (possibly
interrupted) run, which causes adb to error out when trying to upload
them. This patch removes them if they already exist on the device, so we
can test with up-to-date binaries.

The end-to-end lldb tests used to be run only under the purecap ABI.
This patch makes it possible to build and run a test both as purecap and
as hybrid. It also enables most tests to be run for both ABIs. In order
to do so, it sometimes adds `__capability` qualifiers to pointers (e.g.
in order to trigger a capability fault even under the hybrid ABI).

See the updates to the README for the low level details.

Mention that we can run the end-to-end tests either with an FVP model or
a board.

Whilst these are legacy and both GCC and Clang want code to migrate away
from them, many open-source projects make use of them rather than the
GNU __atomic/Clang __c11_atomic intrinsics or standard C(++)11 atomics.
Add support for using them, with both overloaded and explicit forms.