aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran/check.c
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2021-10-12 09:37:25 +0200
committerJakub Jelinek <jakub@redhat.com>2021-10-12 09:37:25 +0200
commit8e1fe3f779185cc678493ceda42c2e620a5c1387 (patch)
treebc1d031d537edf06f7ab8513fb465143f9b32cb5 /gcc/fortran/check.c
parent4096bf82a0cda5f79d7e5921b73897f76e00a800 (diff)
downloadgcc-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