aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/TargetLoweringBase.cpp
diff options
context:
space:
mode:
authorKrzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>2025-06-23 08:09:50 -0500
committerGitHub <noreply@github.com>2025-06-23 08:09:50 -0500
commitfb209929e1b1abbbebae4f3fdbd080c8e54023a1 (patch)
treef646e65b8dad1bc76980c3bfbcd264833ae76b96 /llvm/lib/CodeGen/TargetLoweringBase.cpp
parent9a6a87da6e618d25c23f5f8cf6e4e0f49d4f702c (diff)
downloadllvm-fb209929e1b1abbbebae4f3fdbd080c8e54023a1.zip
llvm-fb209929e1b1abbbebae4f3fdbd080c8e54023a1.tar.gz
llvm-fb209929e1b1abbbebae4f3fdbd080c8e54023a1.tar.bz2
[flang][OpenMP] Set isNewBlock directly on OpenMP constructs (#144593)
When the PFT builder decides that an evaluation needs a new block it checks if the evaluation has nested evaluations. In such case it sets the flag on the first nested evaluation. This works under the assuption that such an evaluation only serves as a container, and does not, by itself, generate any code. This fails for OpenMP constructs that contain nested evaluations because the top-level evaluation does generate code that wraps the code from the nested evaluations. In such cases, the code for the top-level evaluation may be emitted in a wrong place. When setting the `isNewBlock` flag, recognize OpenMP directives, and treat them accordingly. This fixes https://github.com/llvm/llvm-project/issues/139071
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringBase.cpp')
0 files changed, 0 insertions, 0 deletions