aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran/error.cc
diff options
context:
space:
mode:
authorVictor Do Nascimento <victor.donascimento@arm.com>2024-05-21 11:17:45 +0100
committerVictor Do Nascimento <victor.donascimento@arm.com>2024-09-30 15:59:42 +0100
commit2f68d69e47b5b627c6bb71a6bb3d7b2e0e641b2f (patch)
treedad920ef75ebdd6b4674887d915131d362d765a0 /gcc/fortran/error.cc
parent18e905b461a7138185cf4f0efde4a4e1214fb798 (diff)
downloadgcc-2f68d69e47b5b627c6bb71a6bb3d7b2e0e641b2f.zip
gcc-2f68d69e47b5b627c6bb71a6bb3d7b2e0e641b2f.tar.gz
gcc-2f68d69e47b5b627c6bb71a6bb3d7b2e0e641b2f.tar.bz2
optabs: Make all `*dot_prod_optab's modeled as conversions
Given the specification in the GCC internals manual defines the {u|s}dot_prod<m> standard name as taking "two signed elements of the same mode, adding them to a third operand of wider mode", there is currently ambiguity in the relationship between the mode of the first two arguments and that of the third. This vagueness means that, in theory, different modes may be supportable in the third argument. This flexibility would allow for a given backend to add to the accumulator a different number of vectorized products, e.g. A backend may provide instructions for both: accum += a[0] * b[0] + a[1] * b[1] + a[2] * b[2] + a[3] * b[3] and accum += a[0] * b[0] + a[1] * b[1], as is now seen in the SVE2.1 extension to AArch64. In spite of the aforementioned flexibility, modeling the dot-product operation as a direct optab means that we have no way to encode both input and the accumulator data modes into the backend pattern name, which prevents us from harnessing this flexibility. We therefore make all dot_prod optabs conversions, allowing, for example, for the encoding of both 2-way and 4-way dot product backend patterns. gcc/ChangeLog: * optabs.def (sdot_prod_optab): Convert from OPTAB_D to OPTAB_CD. (udot_prod_optab): Likewise. (usdot_prod_optab): Likewise. * doc/md.texi (Standard Names): update entries for u,s and us dot_prod names.
Diffstat (limited to 'gcc/fortran/error.cc')
0 files changed, 0 insertions, 0 deletions