diff options
author | Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com> | 2025-06-23 08:09:50 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-06-23 08:09:50 -0500 |
commit | fb209929e1b1abbbebae4f3fdbd080c8e54023a1 (patch) | |
tree | f646e65b8dad1bc76980c3bfbcd264833ae76b96 /llvm/lib/CodeGen/TargetLoweringBase.cpp | |
parent | 9a6a87da6e618d25c23f5f8cf6e4e0f49d4f702c (diff) | |
download | llvm-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