Reverts llvm/llvm-project#167879 This PR is causing assertions in the check-offload tests: https://lab.llvm.org/staging/#/builders/105 https://lab.llvm.org/staging/#/builders/105/builds/37057
This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and c243406a695ca056a07ef4064b0f9feee7685320, see discussion in https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.
This PR adds a Load method for resources, which takes an additional parameter by reference, status. It fills the status parameter with a 1 or 0, depending on whether or not the resource access was mapped. CheckAccessFullyMapped is also added as an intrinsic, and called in the production of this status bit. Only addresses DXIL for the below issue: https://github.com/llvm/llvm-project/issues/138910 Also only addresses the DXIL variant for the below issue: https://github.com/llvm/llvm-project/issues/99204
Some targets have a specific calling convention that should be used for generated calls to runtime functions. Pass that down and use it. Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
These two classes are mutually exclusive so avoid doing the two checks when the first succeeded.
Firstprivate pointers in OpenMP target regions were not being lowered correctly, causing the runtime to perform unnecessary present table lookups instead of passing pointer values directly. This patch adds the OMP_MAP_LITERAL flag for firstprivate pointers, enabling the runtime to pass pointer values directly without lookups. The fix handles both explicit firstprivate clauses and implicit firstprivate semantics from defaultmap clauses. Key changes: - Track defaultmap(firstprivate:...) clauses in MappableExprsHandler - Add isEffectivelyFirstprivate() to check both explicit and implicit firstprivate semantics - Apply OMP_MAP_LITERAL flag to firstprivate pointers in generateDefaultMapInfo() Map type values: - 288 = OMP_MAP_TARGET_PARAM | OMP_MAP_LITERAL (explicit firstprivate) - 800 = OMP_MAP_TARGET_PARAM | OMP_MAP_LITERAL | OMP_MAP_IS_PTR (implicit firstprivate from defaultmap) Before: Pointers got 544 (TARGET_PARAM | IS_PTR) causing runtime lookups After: Pointers get 288 or 800 (includes LITERAL) for direct pass Updated the 16 existing test cases in OpenMP that were expecting the previous (buggy) behavior. The tests were checking for map type values of 544 (TARGET_PARAM | IS_PTR) and 32 (TARGET_PARAM) for firstprivate pointers, which lacked the LITERAL flag (256). With this fix, firstprivate pointers now correctly include the LITERAL flag, resulting in map types 800 (TARGET_PARAM | LITERAL | IS_PTR) for implicit firstprivate and 288 (TARGET_PARAM | LITERAL) for explicit firstprivate. The updated tests now validate the correct behavior as per OpenMP 5.2 semantics, where firstprivate variables should be passed by value rather than requiring runtime present table lookups. --------- Co-authored-by: Sairudra More <moresair@pe31.hpc.amslabs.hpecorp.net> Co-authored-by: Alexey Bataev <a.bataev@gmx.com>
This partially reverts #152192, keeping updated tests and some code reordering in clang/lib/CodeGen/CGExpr.cpp. compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp is exact revert (with followup #152419) We don't have a good use case for that, so revert it before we are stuck maintaining this API. 21.x does not have this patch. This reverts commit a1209d868632b8aea10450cd2323848ab0b6776a.
d076608d58d1ec55016eb747a995511e3a3f72aa moved some deps around to avoid cycles and left clang/Frontend/FrontendDiagnostic.h as a shim that simply includes clang/Basic/DiagnosticFrontend.h. This PR inlines it so that nothing in tree still includes clang/Frontend/FrontendDiagnostic.h. Doing this will help prevent future layering issues. See #162865. Frontend already depends on Basic, so no new deps need to be added anywhere except for places that do strict dep checking.
Adds the fwidth intrinsic for HLSL. The DXIL path only requires modification to the hlsl headers. The SPIRV path implements the OpFwidth builtin in Clang and instruction selection for the OpFwidth instruction in LLVM. Also adds shader stage tests to the ddx_coarse and ddy_coarse instructions used by fwidth. Closes #99120 --------- Co-authored-by: Alexander Johnston <alexander.johnston@amd.com>
Consider a newly added "malloc_span" attribute in the allocation token instrumentation to ensure that allocation functions with the "malloc_span" attribute are processed similarly to other memory allocation functions. Update the tests to demonstrate applicability to __size_returning_new.