History log of /llvm-project/clang/test/OpenMP/parallel_firstprivate_codegen.cpp (Results 1 – 25 of 94)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3
# 94473f4d 09-Aug-2024 Hari Limaye <hari.limaye@arm.com>

[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)

Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update

[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)

Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update scripts where possible, and by
find + replace where not.

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8
# 12d24e0c 10-Jun-2024 Nikita Popov <npopov@redhat.com>

[CodeGen] Simplify codegen for array initialization (#93956)

This makes codegen for array initialization simpler in two ways:
1. Drop the zero-index GEP at the start, which is no longer needed with

[CodeGen] Simplify codegen for array initialization (#93956)

This makes codegen for array initialization simpler in two ways:
1. Drop the zero-index GEP at the start, which is no longer needed with
opaque pointers.
2. Emit GEPs directly to the correct element, instead of having a long
chain of +1 GEPs. This is more canonical, and also avoids regressions in
unoptimized builds from #93823.

show more ...


Revision tags: llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5
# 970bf07d 06-Nov-2023 Antonio Frighetto <me@antoniofrighetto.com>

[clang][CodeGen] Ensure consistent `mustprogress` attribute emission

Emission of `mustprogress` attribute previously occurred only within
`EmitFunctionBody`, after generating the function body. Othe

[clang][CodeGen] Ensure consistent `mustprogress` attribute emission

Emission of `mustprogress` attribute previously occurred only within
`EmitFunctionBody`, after generating the function body. Other routines
for function body creation may lack the attribute, potentially leading
to suboptimal optimizations later in the pipeline. Attribute emission
is now anticipated prior to generating the function body.

Fixes: https://github.com/llvm/llvm-project/issues/69833.

show more ...


Revision tags: llvmorg-17.0.4
# 84a3aadf 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...


# f5043f46 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...


# 7339c0f7 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they'r

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...


Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2
# 25bc999d 29-Jul-2023 Matt Arsenault <Matthew.Arsenault@amd.com>

Intrinsics: Add type overload to stacksave and stackstore

This allows use with non-0 address space stacks. llvm_ptr_ty should
never be used. This could use some more percolation up through mlir,
but

Intrinsics: Add type overload to stacksave and stackstore

This allows use with non-0 address space stacks. llvm_ptr_ty should
never be used. This could use some more percolation up through mlir,
but this is enough to fix existing tests.

https://reviews.llvm.org/D156666

show more ...


Revision tags: llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 782c59a4 23-Dec-2022 Itay Bookstein <itay.bookstein@nextsilicon.com>

[OpenMP] Prefix outlined and reduction func names with original func's name

This patch prefixes omp outlined helpers and reduction funcs
with the original function's name.

Reviewed By: jdoerfert

D

[OpenMP] Prefix outlined and reduction func names with original func's name

This patch prefixes omp outlined helpers and reduction funcs
with the original function's name.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D140722

show more ...


# 6fdd13e0 19-Apr-2023 Itay Bookstein <itay.bookstein@nextsilicon.com>

Revert "[OpenMP] Prefix outlined and reduction func names with original func's name"

This reverts commit 029bfc311d4d7d3cd90be81bb08c046848796d02.


# 029bfc31 23-Dec-2022 Itay Bookstein <itay.bookstein@nextsilicon.com>

[OpenMP] Prefix outlined and reduction func names with original func's name

This patch attempts to prefix omp outlined helpers and reduction funcs
with the original function's name.

Reviewed By: jd

[OpenMP] Prefix outlined and reduction func names with original func's name

This patch attempts to prefix omp outlined helpers and reduction funcs
with the original function's name.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D140722

show more ...


# 65a0d669 22-Feb-2023 Doru Bercea <doru.bercea@amd.com>

Fix accessing of aligned arrays in offloaded target regions


# f84d30e1 06-Jan-2023 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

Reland "[codegen] Store address of indirect arguments on the stack"

The commit was reverted due to a regression in debug information of an
optimized code test in lldb. This has since been addressed

Reland "[codegen] Store address of indirect arguments on the stack"

The commit was reverted due to a regression in debug information of an
optimized code test in lldb. This has since been addressed by:

1. rGf753e5be8239: [LiveDebugValues] Allow EntryValue with OP_deref
expressions
2. rG055f2f04e658: [mem2reg][debuginfo] Handle op_deref when converting
dbg.declare

Differential Revision: https://reviews.llvm.org/D141381

show more ...


# f2d301fe 16-Jan-2023 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

Revert "[codegen] Store address of indirect arguments on the stack"

This reverts commit 7e4447a17db4a070f01c8f8a87505a4b2a1b0e3a.


# 7e4447a1 06-Jan-2023 Felipe de Azevedo Piovezan <fpiovezan@apple.com>

[codegen] Store address of indirect arguments on the stack

With codegen prior to this patch, truly indirect arguments -- i.e.
those that are not `byval` -- can have their debug information lost even

[codegen] Store address of indirect arguments on the stack

With codegen prior to this patch, truly indirect arguments -- i.e.
those that are not `byval` -- can have their debug information lost even
at O0. Because indirect arguments are passed by pointer, and this
pointer is likely placed in a register as per the function call ABI,
debug information is lost as soon as the register gets clobbered.

This patch solves the issue by storing the address of the parameter on
the stack, using a similar strategy employed when C++ references are
passed. In other words, this patch changes codegen from:

```
define @foo(ptr %arg) {
call void @llvm.dbg.declare(%arg, [...], metadata !DIExpression())
```

To:

```
define @foo(ptr %arg) {
%ptr_storage = alloca ptr
store ptr %arg, ptr %ptr_storage
call void @llvm.dbg.declare(%ptr_storage, [...], metadata !DIExpression(DW_OP_deref))
```

Some common cases where this may happen with C or C++ function calls:
1. "Big enough" trivial structures passed by value under the ARM ABI.
2. Structures that are non-trivial for the purposes of call (as per
the Itanium ABI) when passed by value.

A few tests were matching the wrong alloca (matching against the new
alloca, instead of the old one), so they were updated to either match
both allocas or include a `,` right after the alloca type, to prevent
matching against a pointer type.

Differential Revision: https://reviews.llvm.org/D141381

show more ...


# 8efb8f77 12-Jan-2023 Matt Arsenault <Matthew.Arsenault@amd.com>

OpenMP: Use inbounds in EmitOMPAggregateAssign

This looked like a plausibly correct out of tree patch.
The changed testcases with the pragmas stripped out only use
inbounds GEPs so I assume this is

OpenMP: Use inbounds in EmitOMPAggregateAssign

This looked like a plausibly correct out of tree patch.
The changed testcases with the pragmas stripped out only use
inbounds GEPs so I assume this is correct.

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3
# 40e353d0 07-Oct-2022 Nikita Popov <npopov@redhat.com>

[OpenMP] Convert more tests to opaque pointers (NFC)

These were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34
followed by a re-run of update_cc_test_ch

[OpenMP] Convert more tests to opaque pointers (NFC)

These were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34
followed by a re-run of update_cc_test_checks.py.

show more ...


Revision tags: working, llvmorg-15.0.2, llvmorg-15.0.1
# 839ac62c 15-Sep-2022 Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>

Revert "[OpenMP] Codegen aggregate for outlined function captures"

This reverts commit 7539e9cf811e590d9f12ae39673ca789e26386b4.


# 7539e9cf 15-Sep-2022 Giorgis Georgakoudis <georgakoudis1@llnl.gov>

[OpenMP] Codegen aggregate for outlined function captures

Parallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function's argument lis

[OpenMP] Codegen aggregate for outlined function captures

Parallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function's argument list. That complicates the fork_call interface in the OpenMP runtime: (1) the fork_call is variadic since there is a variable number of arguments to forward to the outlined function, (2) wrapping/unwrapping arguments happens in the OpenMP runtime, which is sub-optimal, has been a source of ABI bugs, and has a hardcoded limit (16) in the number of arguments, (3) forwarded arguments must cast to pointer types, which complicates debugging. This patch avoids those issues by aggregating captured arguments in a struct to pass to the fork_call.

Reviewed By: jdoerfert, jhuber6, ABataev

Differential Revision: https://reviews.llvm.org/D102107

show more ...


Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# b52d33e6 27-Jun-2022 Johannes Doerfert <johannes@jdoerfert.de>

[OpenMP][NFC] Reuse check lines for Clang/OpenMP tests

I used a script to reuse existing check lines rather than creating new
ones. There are more opportunities to reduce the line count but the
"che

[OpenMP][NFC] Reuse check lines for Clang/OpenMP tests

I used a script to reuse existing check lines rather than creating new
ones. There are more opportunities to reduce the line count but the
"check generated functions" logic makes that somewhat tricky.

FWIW, we really should redo the update script with all these use cases
in mind...

Differential Revision: https://reviews.llvm.org/D128686

show more ...


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 532dc62b 07-Apr-2022 Nikita Popov <npopov@redhat.com>

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

Differential Revision: https://reviews.llvm.org/D123115

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# b529744c 18-Feb-2022 hyeongyukim <gusrb406@snu.ac.kr>

[Clang] Rename `disable-noundef-analysis` flag to `-[no-]enable-noundef-analysis`

This flag was previously renamed `enable_noundef_analysis` to
`disable-noundef-analysis,` which is not a conventiona

[Clang] Rename `disable-noundef-analysis` flag to `-[no-]enable-noundef-analysis`

This flag was previously renamed `enable_noundef_analysis` to
`disable-noundef-analysis,` which is not a conventional name. (Driver and
CC1's boolean options are using [no-] prefix)
As discussed at https://reviews.llvm.org/D105169, this patch reverts its
name to `[no-]enable_noundef_analysis` and enables noundef-analysis as
default.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D119998

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3
# 1b1c8d83 16-Jan-2022 hyeongyu kim <gusrb406@snu.ac.kr>

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default.

Test updates are made as a separate patch: D108453

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D105169

show more ...


Revision tags: llvmorg-13.0.1-rc2
# f0ef1ea6 11-Jan-2022 Florian Hahn <flo@fhahn.com>

[IRBuilder] Introduce folder using inst-simplify, use for Or fold.

Alternative to D116817.

This introduces a new value-based folding interface for Or (FoldOr),
which takes 2 values and returns an e

[IRBuilder] Introduce folder using inst-simplify, use for Or fold.

Alternative to D116817.

This introduces a new value-based folding interface for Or (FoldOr),
which takes 2 values and returns an existing Value or a constant if the
Or can be simplified. Otherwise nullptr is returned. This replaces the
more restrictive CreateOr which takes 2 constants.

This is the used to implement a folder that uses InstructionSimplify.
The logic to simplify `Or` instructions is moved there. Subsequent
patches are going to transition other CreateXXX to the more general
FoldXXX interface.

Reviewed By: nikic, lebedev.ri

Differential Revision: https://reviews.llvm.org/D116935

show more ...


# 1201a0f3 22-Dec-2021 Nikita Popov <npopov@redhat.com>

[OpenMP] Fix incorrect type when casting from uintptr

MakeNaturalAlignAddrLValue() expects the pointee type, but the
pointer type was passed. As a result, the natural alignment of
the pointer (usual

[OpenMP] Fix incorrect type when casting from uintptr

MakeNaturalAlignAddrLValue() expects the pointee type, but the
pointer type was passed. As a result, the natural alignment of
the pointer (usually 8) was always used in place of the natural
alignment of the value type.

Differential Revision: https://reviews.llvm.org/D116171

show more ...


# 0fe1ccc7 22-Dec-2021 Nikita Popov <npopov@redhat.com>

[OpenMP] Regenerate test checks (NFC)

Regenerate test checks to reduce diff for an upcoming patch.


1234