[gn] Add clang_static_plugin_sources to link out-of-tree plugins into clang (#226381)
This is useful for testing and profiling e.g. Chromium's clang plugins
without having to export symbols from the clang binary.
# args.gn
clang_static_plugin_sources = [
"/path/to/chromium/src/tools/clang/plugins/FindBadConstructsAction.cpp",
...
]
clang_static_plugin_include_dirs = [ "/path/to/chromium/src" ]
...or put the above in a gni file and put just `import("plugins.gni")`
in args.gn
No behavior change if the list is empty (the default).
[AMDGPU] Fix dynamic LDS consistency check in setDynLDSAlign (#225825)
5bf967cb132b ("[RFC][AMDGPU] Add BARRIER address space") changed the
absolute-address check in `setDynLDSAlign` to read the dynamic LDS
global being lowered (`GV`) instead of the kernel's representative
`llvm.amdgcn.<kernel>.dynlds` variable (`Dyn`).
`amdgpu-lower-module-lds` attaches `!absolute_symbol` only to the
representative; uses of the original dynamic LDS global inside the
kernel are left in place and never carry that metadata. As a result, a
kernel that accesses dynamic LDS both directly and through a non-inlined
callee now aborts with "Inconsistent metadata on dynamic LDS variable".
[flang][OpenMP] Rename some symbols in check-omp-syntax.cpp (#226484)
Some function names did not conform to the naming convention. Include a
couple of other non-significant changes.
[offload][omp] Load and resolve device binaries through liboffload
Migrate DeviceTy::loadBinary and global/kernel symbol resolution off
GenericPluginTy::load_binary/get_global/get_function onto liboffload's
Program/Symbol API, encapsulated in a new ProgramTy abstraction that wraps
an ol_program_handle_t. Kernel symbol resolution still needs the plugin's
opaque GenericKernelTy* handle for the legacy launch path, obtained via a
temporary __ol_tgt_GetKernelFromSymbol helper rather than new public
liboffload API surface. Removes the now-dead __tgt_device_binary type and
the corresponding GenericPluginTy methods and exports entries.
[offload][omp] Route RPC callback registration through liboffload
Replace __tgt_register_rpc_callback's direct iteration over plugins
with olIteratePlatforms + olPlatformRegisterRPCCallback, and drop the
now-unused RPCServerTy::registerCallback export. Move the
initialized/has-devices guard that used to live in libomptarget into
olPlatformRegisterRPCCallback_impl.
[offload][omp] Query device info directly through liboffload
Route DeviceTy::getInfo through olGetDeviceInfo instead of the
plugin's obtain_device_info, and drop the now-unused
GenericPluginTy::obtain_device_info wrapper and its liboffload
export.
[offload][omp] Manage memory allocation through liboffload
Migrate DeviceTy::allocData/deleteData off GenericPluginTy::data_alloc/
data_delete onto liboffload's olMemAlloc*/olMemFree, migrate
targetLockExplicit/targetUnlockExplicit off data_lock/data_unlock onto
olMemRegister/olMemUnregister (fixing a latent bug where these passed
the OpenMP-visible device number instead of the plugin device id), and
migrate DeviceTy::isAccessiblePtr onto a new olMemIsAccessible API
(added with a unit test) since liboffload had no equivalent for
querying accessibility of arbitrary, not-necessarily-liboffload-
allocated pointers. Removes the now-dead GenericPluginTy::data_alloc/
data_delete/data_lock/data_unlock/is_accessible_ptr wrappers and their
exports entries.
[offload][omp] Remove data_fence
All supported backends execute enqueued work on a given queue in
submission order (CUDA, AMDGPU, and Host queues are always in-order;
Level Zero's default and non-default in-order/synchronous command
modes are as well), so the explicit data-fence used to order a
pointer-attachment after prior data transfers is unnecessary. Remove
the DeviceTy/GenericDeviceTy/GenericPluginTy dataFence chain and the
now-unused olQueueBarrier liboffload API added to support it.
[Polly] Do not assume loops to be bounded if latch conditions are invalid (#226202)
If a loop with an `<nsw>` induction variable appears to be unbounded for
some parameter values, `addLoopBoundsToHeaderDomain` removes them from
its domain without a runtime check, but the loop may only appear
unbounded because its latch condition is modeled incorrectly for these
values, e.g. `(zext i16 %n to i64)` is modeled as `n` under the
assumption `n >= 0`. Removing them also dropped that assumption, so for
`n < 0` the loop was not executed at all instead of running `65536 + n`
iterations. Exclude the parameter values for which the latch conditions
are invalid by a runtime check instead.
Fixes #192616 and #192618.
Assisted-by: Claude (Anthropic)
