forked from llvm/llvm-project
-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Initial test for a mapper that doesn't make too many bindings #20
Draft
gbaraldi
wants to merge
15
commits into
julia-release/16.x
Choose a base branch
from
gb/memory_manager
base: julia-release/16.x
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
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
Otherwise clang installs all of its tools into `bin/` while LLVM installs its tools into (LLVM_TOOLS_INSTALL_DIR). I could swear this used to work (and in fact the julia build system assumes it), but I can't pin down a specific commit that would have broken this, and julia has been relying on pre-compiled binaries for a while now (that don't use this setting), so it may have been broken for quite a while. Differential Revision: https://reviews.llvm.org/D88630 (cherry picked from commit 6104e14) (cherry picked from commit f252e17) (cherry picked from commit 9039ce8)
IIUC we can't emit `memcmp` between pointers in addressspaces, doing so will trigger an assertion since the signature of the memcmp will not match it's arguments (https://bugs.llvm.org/show_bug.cgi?id=48661). This PR disables the attempt to merge icmps, when the pointer is in an addressspace. Differential Revision: https://reviews.llvm.org/D94813 (cherry picked from commit 458b259) (cherry picked from commit aaf2d27)
(cherry picked from commit 5393efb)
Co-authored-by: Valentin Churavy <[email protected]> Co-authored-by: Julian P Samaroo <[email protected]> (cherry picked from commit a0defe0)
Follow-up on https://reviews.llvm.org/D118970 FP_XSTATE_MAGIC1 is only available on glibc 2.27 and upwards Differential Revision: https://reviews.llvm.org/D124770
We need to force the emission of the EH Frame section (currently done via SupportsCompactUnwindWithoutEHFrame in the MCObjectFileInfo for the target), since libunwind doesn't yet support dynamically registering compact unwind information at run-time. (cherry picked from commit 60e0418) (cherry picked from commit 6275013)
PrintIRInstrumentation::shouldPrintAfterPass accepts a pass ID instead of a pass name Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D147394 (cherry picked from commit d4de7c2)
`SimplifySelectOps` is a late optimization in LLVM that attempts to translate `select(C, load(A), load(B))` into `load(select(C, A, B))`. However, in order for it to do this optimization, it needs to check that `C` does not depend on the result of `load(A)` or `load(B)`. Unfortunately (unlikely Julia and LLVM at the IR level), LLVM does not have a topological order of statements computed at this stage of the compiler, so LLVM needs to iterate through all statements in the function in order to perform this legality check. For large functions, this is extremely expensive, accounting for the majority of all compilation time for such functions. On the other hand, the optimization itself is minor, allowing at most the elision of one additional load (and doesn't fire particularly often, because the middle end can perform similar optimizations). Until there is a proper solution in LLVM, simply disable this optimizations, making LLVM several orders of magnitude faster on real world benchmarks. X-ref: llvm#60132
As shown in issue llvm#60649, the new shuffles were being inserted before a phi, and that is invalid. It seems like most test coverage for this fold (foldSelectShuffle) lives in the AArch64 dir, but this doesn't repro there for a base target.
Do we need to implement it within the LLVM source tree, or could we have it within the Julia source code and contribute it upstream later? |
I think we want it upstream. But we likely want ot backport it as well. |
vchuravy
force-pushed
the
julia-release/16.x
branch
2 times, most recently
from
October 6, 2023 16:59
7116ea1
to
47769d3
Compare
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.
No description provided.