diff options
author | Victor Do Nascimento <victor.donascimento@arm.com> | 2024-05-21 11:17:45 +0100 |
---|---|---|
committer | Victor Do Nascimento <victor.donascimento@arm.com> | 2024-09-30 15:59:42 +0100 |
commit | 2f68d69e47b5b627c6bb71a6bb3d7b2e0e641b2f (patch) | |
tree | dad920ef75ebdd6b4674887d915131d362d765a0 /gcc/fortran/error.cc | |
parent | 18e905b461a7138185cf4f0efde4a4e1214fb798 (diff) | |
download | gcc-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