[pull] main from llvm:main #154
Merged
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
"darwin" is ambiguous. When there isn't a better source of truth (e.g., SDKs), the driver will either interpret it as "iOS" when cross-compiling to a different architecture, or "the host" when not. That's now the case on AS Macs. Update the test to more explicitly test the OS. aarch64-mac-cpus.c already tests the mac-specific driver logic.
This commit substantially refactors the JITLinkMemoryManager API to: (1) add
asynchronous versions of key operations, (2) give memory manager implementations
full control over link graph address layout, (3) enable more efficient tracking
of allocated memory, and (4) support "allocation actions" and finalize-lifetime
memory.
Together these changes provide a more usable API, and enable more powerful and
efficient memory manager implementations.
To support these changes the JITLinkMemoryManager::Allocation inner class has
been split into two new classes: InFlightAllocation, and FinalizedAllocation.
The allocate method returns an InFlightAllocation that tracks memory (both
working and executor memory) prior to finalization. The finalize method returns
a FinalizedAllocation object, and the InFlightAllocation is discarded. Breaking
Allocation into InFlightAllocation and FinalizedAllocation allows
InFlightAllocation subclassses to be written more naturally, and FinalizedAlloc
to be implemented and used efficiently (see (3) below).
In addition to the memory manager changes this commit also introduces a new
MemProt type to represent memory protections (MemProt replaces use of
sys::Memory::ProtectionFlags in JITLink), and a new MemDeallocPolicy type that
can be used to indicate when a section should be deallocated (see (4) below).
Plugin/pass writers who were using sys::Memory::ProtectionFlags will have to
switch to MemProt -- this should be straightworward. Clients with out-of-tree
memory managers will need to update their implementations. Clients using
in-tree memory managers should mostly be able to ignore it.
Major features:
(1) More asynchrony:
The allocate and deallocate methods are now asynchronous by default, with
synchronous convenience wrappers supplied. The asynchronous versions allow
clients (including JITLink) to request and deallocate memory without blocking.
(2) Improved control over graph address layout:
Instead of a SegmentRequestMap, JITLinkMemoryManager::allocate now takes a
reference to the LinkGraph to be allocated. The memory manager is responsible
for calculating the memory requirements for the graph, and laying out the graph
(setting working and executor memory addresses) within the allocated memory.
This gives memory managers full control over JIT'd memory layout. For clients
that don't need or want this degree of control the new "BasicLayout" utility can
be used to get a segment-based view of the graph, similar to the one provided by
SegmentRequestMap. Once segment addresses are assigned the BasicLayout::apply
method can be used to automatically lay out the graph.
(3) Efficient tracking of allocated memory.
The FinalizedAlloc type is a wrapper for an ExecutorAddr and requires only
64-bits to store in the controller. The meaning of the address held by the
FinalizedAlloc is left up to the memory manager implementation, but the
FinalizedAlloc type enforces a requirement that deallocate be called on any
non-default values prior to destruction. The deallocate method takes a
vector<FinalizedAlloc>, allowing for bulk deallocation of many allocations in a
single call.
Memory manager implementations will typically store the address of some
allocation metadata in the executor in the FinalizedAlloc, as holding this
metadata in the executor is often cheaper and may allow for clean deallocation
even in failure cases where the connection with the controller is lost.
(4) Support for "allocation actions" and finalize-lifetime memory.
Allocation actions are pairs (finalize_act, deallocate_act) of JITTargetAddress
triples (fn, arg_buffer_addr, arg_buffer_size), that can be attached to a
finalize request. At finalization time, after memory protections have been
applied, each of the "finalize_act" elements will be called in order (skipping
any elements whose fn value is zero) as
((char*(*)(const char *, size_t))fn)((const char *)arg_buffer_addr,
(size_t)arg_buffer_size);
At deallocation time the deallocate elements will be run in reverse order (again
skipping any elements where fn is zero).
The returned char * should be null to indicate success, or a non-null
heap-allocated string error message to indicate failure.
These actions allow finalization and deallocation to be extended to include
operations like registering and deregistering eh-frames, TLS sections,
initializer and deinitializers, and language metadata sections. Previously these
operations required separate callWrapper invocations. Compared to callWrapper
invocations, actions require no extra IPC/RPC, reducing costs and eliminating
a potential source of errors.
Finalize lifetime memory can be used to support finalize actions: Sections with
finalize lifetime should be destroyed by memory managers immediately after
finalization actions have been run. Finalize memory can be used to support
finalize actions (e.g. with extra-metadata, or synthesized finalize actions)
without incurring permanent memory overhead.
This reverts commit e50aea5 while I investigate bot failures.
In the original design, we levarage _mt intrinsics to define macros for _m intrinsics. Such as, ``` __builtin_rvv_vadd_vv_i8m1_mt((vbool8_t)(op0), (vint8m1_t)(op1), (vint8m1_t)(op2), (vint8m1_t)(op3), (size_t)(op4), (size_t)VE_TAIL_AGNOSTIC) ``` However, we could not define generic interface for mask intrinsics any more due to clang_builtin_alias only accepts clang builtins as its argument. In the example, ``` __rvv_overloaded __attribute__((clang_builtin_alias(__builtin_rvv_vadd_vv_i8m1_mt))) vint8m1_t vadd(vbool8_t op0, vint8m1_t op1, vint8m1_t op2, vint8m1_t op3, size_t op4, size_t op5); ``` op5 is the tail policy argument. When users want to use vadd generic interface for masked vector add, they need to specify tail policy in the previous design. In this patch, we define _m intrinsics as clang builtins to solve the problem. Differential Revision: https://reviews.llvm.org/D110684
Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D110681
This warning should only be issued if -slab-page-size has not been used.
Per discussion in https://reviews.llvm.org/D111199, the existing btf_tag attribute will be renamed to btf_decl_tag. This patch mostly updated the Bitcode and DebugInfo test cases with new attribute name. Differential Revision: https://reviews.llvm.org/D111591
All those frame indices which are dead after sgpr spill should be removed from the function frame. Othewise, there is a side effect such as re-mapping of free frame index ids by the later pass(es) like "stack slot coloring" which in turn could mess-up with the book keeping of "frame index to VGPR lane". Reviewed By: cdevadas Differential Revision: https://reviews.llvm.org/D111150
Sequel patch to https://reviews.llvm.org/D111293. Remove call to CodeGenFunction::InitTempAlloca() from OpenMP related codegen part. Also remove the metadata `!llvm.access.group` from the updated lit tests. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D111316
Per discussion in https://reviews.llvm.org/D111199, the existing btf_tag attribute will be renamed to btf_decl_tag. This patch updated BTF backend to use btf_decl_tag attribute name and also renamed BTF_KIND_TAG to BTF_KIND_DECL_TAG. Differential Revision: https://reviews.llvm.org/D111592
Sequel patch to https://reviews.llvm.org/D111316 Finally, remove the defintion of CodeGenFunction::InitTempAlloca(). Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D111324
Adds explicit narrowing casts to JITLinkMemoryManager.cpp. Honors -slab-address option in llvm-jitlink.cpp, which was accidentally dropped in the refactor. This effectively reverts commit 6641d29.
This should fix the buildbot failure at https://lab.llvm.org/buildbot/#/builders/187/builds/2140
Add the additional flags from D36850 as well as noInline/alwaysInline from previous changes. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D111600
Current btf_tag is applied to declaration only. Per discussion in https://reviews.llvm.org/D111199, we plan to introduce btf_type_tag attribute for types. So rename btf_tag to btf_decl_tag to make it easily differentiable from btf_type_tag. Differential Revision: https://reviews.llvm.org/D111588
See e.g. https://lab.llvm.org/buildbot/#/builders/193/builds/98. I think this failure is related to a C++ standard defect, 1397 --"Class completeness in non-static data member initializers" [1]. If so, moving to C++98 initialization should work around the issue. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1397
Commit 731f991 seems to have helped, but did not catch all instances (see https://lab.llvm.org/buildbot/#/builders/193/builds/104). Switch more inner structs to C++98 initializers to work around the issue. Add FIXMEs to revisit in the future.
…ons for v1.0-rc change Rename vfredsum and vfwredsum to vfredusum and vfwredusum. Add aliases for vfredsum and vfwredsum. Reviewed By: luismarques, HsiangKai, khchen, frasercrmck, kito-cheng, craig.topper Differential Revision: https://reviews.llvm.org/D105690
Add two test for needExternalNameMangling. - One varibale in a function - One namelist in a module This patch is part of the upstreaming effort from fir-dev branch. Reviewed By: schweitz Differential Revision: https://reviews.llvm.org/D111544
…earch::lookupModule` This patch propagates the import `SourceLocation` into `HeaderSearch::lookupModule`. This enables remarks on search path usage (implemented in D102923) to point to the source code that initiated header search. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D111557
…Clang Reviewed By: pratlucas Differential Revision: https://reviews.llvm.org/D110241
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )