- 23 Jan, 2023 1 commit
-
-
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
-
- 20 Jan, 2023 8 commits
-
-
Alex Richardson authored
When NEON is disabled, we were up using non-C64 loads/stores for the COPY. Fix this by updating AArch64InstrInfo::copyPhysReg().
-
Alex Richardson authored
When NEON is disabled, we end up using non-C64 loads/stores for the COPY.
-
Alex Richardson authored
We shedule instructions slightly differently with the current Morello LLVM.
-
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)
-
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)
-
Differential Revision: https://reviews.llvm.org/D125240 (cherry picked from commit f8639133b58dd7335474dfa9dbb04b13098c5294)
-
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)
-
(cherry picked from commit 32a353a5e08628403422a1f71e6500bc1f68e8fb)
-
- 19 Jan, 2023 1 commit
-
-
Silviu Baranga authored
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
-
- 09 Jan, 2023 1 commit
-
-
Silviu Baranga authored
defaulting to c30. Fixes #63
-
- 16 Dec, 2022 1 commit
-
-
Silviu Baranga authored
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.
-
- 12 Dec, 2022 1 commit
-
-
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
-
- 22 Nov, 2022 1 commit
-
-
[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)
-
- 04 Nov, 2022 1 commit
-
-
Silviu Baranga authored
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.
-
- 26 Oct, 2022 1 commit
-
-
Jessica Clarke authored
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.
-
- 25 Oct, 2022 1 commit
-
-
Alex Richardson authored
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.
-
- 11 Oct, 2022 1 commit
-
-
Silviu Baranga authored
it use scbnds instead of scbndse (in hybrid we're not guaranteed that the capability would be representable).
-
- 03 Oct, 2022 4 commits
-
-
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)
-
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)
-
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)
-
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)
-
- 30 Sep, 2022 1 commit
-
-
Silviu Baranga authored
We need the size of the capability to match exactly the size of the memory transfer to do this.
-
- 28 Sep, 2022 1 commit
-
-
Jessica Clarke authored
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).
-
- 16 Sep, 2022 1 commit
-
-
Diana Picus authored
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.
-
- 15 Sep, 2022 1 commit
-
-
Diana Picus authored
* Trim potential trailing / on the input ANDROID_OUT
-
- 30 Aug, 2022 1 commit
-
-
Silviu Baranga authored
branches
-
- 26 Aug, 2022 3 commits
-
-
Alex Richardson authored
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.
-
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)
-
Alex Richardson authored
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.
-
- 17 Aug, 2022 2 commits
-
-
-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
-
-
- 27 Jul, 2022 1 commit
-
-
Silviu Baranga authored
using a pseudoinst. This guarantees that MachineLICM can't hoist the adrp and not the ldr.
-
- 26 Jul, 2022 1 commit
-
-
Silviu Baranga authored
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.
-
- 22 Jul, 2022 2 commits
-
-
Silviu Baranga authored
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.
-
Silviu Baranga authored
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.
-
- 21 Jul, 2022 3 commits
-
-
Diana Picus authored
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.
-
Diana Picus authored
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.
-
Diana Picus authored
Mention that we can run the end-to-end tests either with an FVP model or a board.
-
- 18 Jul, 2022 1 commit
-
-
Jessica Clarke authored
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.
-