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

Initial test for a mapper that doesn't make too many bindings #20

Draft
wants to merge 15 commits into
base: julia-release/16.x
Choose a base branch
from

Conversation

gbaraldi
Copy link
Member

No description provided.

vchuravy and others added 15 commits April 30, 2023 13:29
…nces"

This reverts commit 5a5ac65.

(cherry picked from commit ae2638d)
(cherry picked from commit 05848b6)
Julia uses addressspaces for GC and we want these to be sanitized as well.

(cherry picked from commit 3f53397)
(cherry picked from commit 58df73b)
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)
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.
@vchuravy
Copy link
Member

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?

@gbaraldi
Copy link
Member Author

gbaraldi commented Aug 16, 2023

I think we want it upstream. But we likely want ot backport it as well.

@vchuravy vchuravy force-pushed the julia-release/16.x branch 2 times, most recently from 7116ea1 to 47769d3 Compare October 6, 2023 16:59
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.

7 participants