diff options
author | Jakub Jelinek <jakub@redhat.com> | 2021-10-12 09:37:25 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2021-10-12 09:37:25 +0200 |
commit | 8e1fe3f779185cc678493ceda42c2e620a5c1387 (patch) | |
tree | bc1d031d537edf06f7ab8513fb465143f9b32cb5 /gcc/fortran/check.c | |
parent | 4096bf82a0cda5f79d7e5921b73897f76e00a800 (diff) | |
download | gcc-8e1fe3f779185cc678493ceda42c2e620a5c1387.zip gcc-8e1fe3f779185cc678493ceda42c2e620a5c1387.tar.gz gcc-8e1fe3f779185cc678493ceda42c2e620a5c1387.tar.bz2 |
openmp: Avoid calling clear_type_padding_in_mask in the common case where there can't be any padding
We can use the clear_padding_type_may_have_padding_p function, which
is conservative for e.g. RECORD_TYPE/UNION_TYPE, but for the floating and
complex floating types is accurate. clear_type_padding_in_mask is
more expensive because we need to allocate memory, fill it, call the function
which itself is more expensive and then analyze the memory, so for the
common case of float/double atomics or even long double on most targets
we can avoid that.
2021-10-12 Jakub Jelinek <jakub@redhat.com>
gcc/
* gimple-fold.h (clear_padding_type_may_have_padding_p): Declare.
* gimple-fold.c (clear_padding_type_may_have_padding_p): No longer
static.
gcc/c-family/
* c-omp.c (c_finish_omp_atomic): Use
clear_padding_type_may_have_padding_p.
Diffstat (limited to 'gcc/fortran/check.c')
0 files changed, 0 insertions, 0 deletions