forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Aug 31, 2023
smeenai
force-pushed
the
spr/main/3ee32858
branch
from
September 1, 2023 01:17
9c08378
to
973e4a1
Compare
smeenai
force-pushed
the
spr/main/e61775a8
branch
from
September 1, 2023 01:17
3d1109f
to
7f21e1d
Compare
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
commit-id:f92a3c24
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
commit-id:5b947253
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
This was referenced Sep 1, 2023
This was referenced Sep 1, 2023
smeenai
force-pushed
the
spr/main/e61775a8
branch
from
September 1, 2023 01:19
7f21e1d
to
8dd31ac
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 Clangnormalizes to
android
. If you use theandroideabi
triple whenbuilding the runtimes with a per-target runtimes dir, the directory will
get created with
androideabi
in its name, but Clang's triple searchuses the normalized triple and will look for an
android
directoryinstead. 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