llvm-project

622f72f4 - [OpenMP] Fix firstprivate pointer handling in target regions (#167879)

[OpenMP] Fix firstprivate pointer handling in target regions (#167879) 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>