Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[driver] Search for compatible Android runtime directories #6

Closed
wants to merge 21 commits into from

Conversation

smeenai
Copy link
Owner

@smeenai smeenai commented Aug 31, 2023

Android triples include a version number, which makes direct triple
comparisons for per-target runtime directory searching not always work.
Instead, look for the triple with the highest compatible version number
and use that per-target runtime directory instead. This maintains the
existing fallback to a triple without any version number, but I'm hoping
we can remove that in the future. https://discourse.llvm.org/t/62717
discusses this further.

The one remaining triple mismatch after this is that Android armv7
triples usually have an environment of androideabi, which Clang
normalizes to android. If you use the androideabi triple when
building the runtimes with a per-target runtimes dir, the directory will
get created with androideabi in its name, but Clang's triple search
uses the normalized triple and will look for an android directory
instead. https://reviews.llvm.org/D140925 will fix that by normalizing
triples when creating the per-target runtimes directories as well.

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

ghstack-source-id: 7829a156cc455192c02fd7b23819fa26ffbca730
Pull Request resolved: #3

hjyamauchi and others added 21 commits August 31, 2023 18:18
but there are some in the epilogue.

Make a decision whether or not to have a startepilogue/endepilogue
based on whether we actually insert SEH opcodes in the epilogue,
rather than whether we had SEH opcodes in the prologue or not.

This fixes an assert failure when there are no SEH opcodes in the
prologue but there are SEH opcodes in the epilogue (for example, when
there is no stack frame but there are stack arguments) which was not
covered in https://reviews.llvm.org/D88641.

Assertion failed: HasWinCFI == MF.hasWinCFI(), file C:\Users\hiroshi\llvm-project\llvm\lib\Target\AArch64\AArch64FrameLowering.cpp, line 1988

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

commit-id:b6dfb05c
…th()

Extends readability-container-size-empty to check std::string length() similar to size().

Fixes: llvm#37603

Co-authored-by: Dmitry Venikov <[email protected]>

Reviewed By: carlosgalvezp

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

commit-id:56527293
Modify script to fail when some run clang-tidy
command fails. Based on run_clang-tidy.

Fixes: llvm#65000

Reviewed By: carlosgalvezp

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

commit-id:f05b3f73
This patch adds the necessary support to provide `assert` functionality
through the GPU `libc` implementation. This implementation creates a
special-case GPU implementation rather than relying on the common
version. This is because the GPU has special considerings for printing.
The assertion is printed out in chunks with `write_to_stderr`, however
when combined with the GPU execution model this causes 32+ threads to
all execute in-lock step. Meaning that we'll get a horribly fragmented
message. Furthermore, potentially thousands of threads could hit the
assertion at once and try to print even if we had it all in one
`printf`.

This is solved by having a one-time lock that each thread group / wave /
warp will attempt to claim. We only let one thread group pass through
while the others simply stop executing. Finally only the first thread in
that group will do the printing until we finally abort execution.

Reviewed By: sivachandra

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

commit-id:a8e5550c
commit-id:5034482e
Reviewed By: fmayer

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

commit-id:36ac8129
This reverts commit f281543.

Sami Tolvanen reports that this breaks the Linux kernel's arch=RISCV
defconfig.

Link: ClangBuiltLinux/linux#1928

commit-id:96287f6b
The inline link to RankedTensorType in UnrankedTensorType section
and the inline link to MemRefType in UnrankedMemrefType section
are all invalid. This patch update these link.

Reviewed By: aartbik

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

commit-id:3d7d3446
With the large code model, the label difference may not fit into 32 bits.
Even if we assume that any individual function is no larger than 2^32
and use a difference from the function entry to the target destination,
things like BOLT can rearrange blocks (even if BOLT doesn't necessarily
work with the large code model right now).

set directives avoid static relocations in some 32-bit entry cases, but
don't worry about set directives for 64-bit jump table entries (we can
do that later if somebody really cares about it).

check-llvm in a bootstrapped clang with the large code model passes.

Fixes llvm#62894

Reviewed By: rnk

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

commit-id:9020bd5e
Ensure these don't regress the next time we reland D152495.

Link: ClangBuiltLinux/linux#1926

Reviewed By: cor3ntin, MaskRay

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

commit-id:21e75626
This should fix the test failure in breakpoint_function_callback.test
since SBStructuredData can now display the content of SBStructuredData.

Signed-off-by: Med Ismail Bennani <[email protected]>

commit-id:8cb218e1
Currently AlignArrayOfStructures=Left is hard coding setting Spaces to
0 for the token following the initial opening brace, but not touching
Spaces for the subsequent lines, which leads to the array being
misaligned. Additionally, it's not adding a space before the trailing
} which is generally done when Cpp11BracedListStyle=false.

I'm not exactly sure why this function needs to override the Spaces as
it seems to generally already be set to either 0 or 1 according to
the other formatting settings, but I'm going with an explicit fix where
I just force the padding to 1 when Cpp11BracedListStyle=false.

AlignArrayOfStructures=Right doesn't have any alignment problems, but
isn't adding the expected padding around the braces either, so I'm
giving that the same treatment.

Fixes llvm#57611.

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

commit-id:e09cfa2b
This reverts commit ef4beb8.

It also removes the prior note about needing to patch ``arcanist``.

This is patch is no longer necessary:
1. arcanist came out of hibernation and updated to support PHP 8.1.
   https://github.com/phacility/arcanist/commits/master
2. llvm/llvm-project is moving to github pull requests starting Sept 1
   (tomorrow).
   https://discourse.llvm.org/t/pull-request-migration-schedule/71595

Fixes: llvm#64470

Reviewed By: MaskRay

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

commit-id:94c4d093
Irritatingly, atomic_store had operands in the opposite order from
regular store. This made it difficult to share patterns between
regular and atomic stores.

There was a previous incomplete attempt to move atomic_store into the
regular StoreSDNode which would be better.

I think it was a mistake for all atomicrmw to swap the operand order,
so maybe it's better to take this one step further.

https://reviews.llvm.org/D123143

commit-id:ebe3b848
This version can be used without a PassManager

https://reviews.llvm.org/D133784

commit-id:6d8f13a1
In Apple's downstream fork, there is support for understanding the swift
AST sections in various binaries. Even though the lldb on llvm.org does
not have support for debugging swift, I think it makes sense to move
support for recognizing swift ast sections upstream.

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

commit-id:ade5f2f5
https://reviews.llvm.org/D71154 prevented Clang from search for libc++
headers installed alongside the driver when targeting Android. The
motivation was the NDK's use of a different libc++ inline namespace
(`__ndk1` instead of the standard `__1`), which made regular libc++
headers incompatible with the NDK's libc++ library.

Since then, libc++ has gained the ability to install its `__config_site`
header (which controls the inline namespace, among other things) to a
per-target include directory, which enables per-target customizations.
If this directory is present, the user has expressly built libc++ for
Android, and we should use those headers.

The motivation is that, with the current setup, if a user builds their
own libc++ for Android, they'll use the library they built themselves
but the NDK's headers instead of their own, which is surprising at best
and can cause all sorts of problems (e.g. if you built your own libc++
with a different ABI configuration). It's important to match the headers
and libraries in that scenario, and checking for an Android per-target
include directory lets us do so without regressing the original scenario
which https://reviews.llvm.org/D71154 was addressing.

While I'm here, switch to using sys::path::append instead of slashes
directly, to get system path separators on Windows, which is consistent
with how library paths are constructed (and that consistency will be
important in a follow-up, where we use a common search function for the
include and library path construction).

(As an aside, one of the motivations for https://reviews.llvm.org/D71154
was to support targeting both Android and Apple platforms, which
expected libc++ headers to be provided by the toolcain at the time.
Apple has since switched to including libc++ headers in the platform SDK
instead of in the toolchain, so that specific motivation no longer
applies either.)

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

ghstack-source-id: b3784216d8b0a4ea897b8058cb8cad81ffaac0ec
Pull Request resolved: #1

commit-id:4bf3c603
Searching for target-specific standard library header and library paths
should perform fallback searches for targets, the same way searching for
the runtime libraries does. It's important for the header and library
searches to be consistent, otherwise we could end up using mismatched
headers and libraries. (See also https://reviews.llvm.org/D146664.)

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

ghstack-source-id: c470bd6846cfc7cec86ca77c3e1806599d2e00a8
Pull Request resolved: #2

commit-id:3ee32858
Android triples include a version number, which makes direct triple
comparisons for per-target runtime directory searching not always work.
Instead, look for the triple with the highest compatible version number
and use that per-target runtime directory instead. This maintains the
existing fallback to a triple without any version number, but I'm hoping
we can remove that in the future. https://discourse.llvm.org/t/62717
discusses this further.

The one remaining triple mismatch after this is that Android armv7
triples usually have an environment of `androideabi`, which Clang
normalizes to `android`. If you use the `androideabi` triple when
building the runtimes with a per-target runtimes dir, the directory will
get created with `androideabi` in its name, but Clang's triple search
uses the normalized triple and will look for an `android` directory
instead. https://reviews.llvm.org/D140925 will fix that by normalizing
triples when creating the per-target runtimes directories as well.

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

ghstack-source-id: 7829a156cc455192c02fd7b23819fa26ffbca730
Pull Request resolved: #3

commit-id:e61775a8
smeenai pushed a commit that referenced this pull request Oct 2, 2023
…fine.parallel verifier

This patch updates AffineParallelOp::verify() to check each result type matches
its corresponding reduction op (i.e, the result type must be a `FloatType` if
the reduction attribute is `addf`)

affine.parallel will crash on --lower-affine if the corresponding result type
cannot match the reduction attribute.

```
      %128 = affine.parallel (%arg2, %arg3) = (0, 0) to (8, 7) reduce ("maxf") -> (memref<8x7xf32>) {
        %alloc_33 = memref.alloc() : memref<8x7xf32>
        affine.yield %alloc_33 : memref<8x7xf32>
      }
```
This will crash and report a type conversion issue when we run `mlir-opt --lower-affine`

```
Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file Casting.h, line 572.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: mlir-opt --lower-affine temp.mlir
 #0 0x0000000102a18f18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/workspacebin/mlir-opt+0x1002f8f18)
 #1 0x0000000102a171b4 llvm::sys::RunSignalHandlers() (/workspacebin/mlir-opt+0x1002f71b4)
 #2 0x0000000102a195c4 SignalHandler(int) (/workspacebin/mlir-opt+0x1002f95c4)
 #3 0x00000001be7894c4 (/usr/lib/system/libsystem_platform.dylib+0x1803414c4)
 #4 0x00000001be771ee0 (/usr/lib/system/libsystem_pthread.dylib+0x180329ee0)
 #5 0x00000001be6ac340 (/usr/lib/system/libsystem_c.dylib+0x180264340)
 #6 0x00000001be6ab754 (/usr/lib/system/libsystem_c.dylib+0x180263754)
 #7 0x0000000106864790 mlir::arith::getIdentityValueAttr(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (.cold.4) (/workspacebin/mlir-opt+0x104144790)
 #8 0x0000000102ba66ac mlir::arith::getIdentityValueAttr(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (/workspacebin/mlir-opt+0x1004866ac)
 #9 0x0000000102ba6910 mlir::arith::getIdentityValue(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (/workspacebin/mlir-opt+0x100486910)
...
```

Fixes llvm#64068

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D157985
@smeenai smeenai closed this Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.