On Wed, Mar 1, 2023 at 12:07 AM Andrew Pinski via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Tue, Feb 28, 2023 at 3:02 PM Kwok Cheung Yeung <k...@codesourcery.com> > wrote: > > > > Hello > > > > This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION > > target hook for the AMD GCN architecture, such that when vectorized, > > calls to builtin standard math functions such as asinf, exp, pow etc. > > are converted to calls to the recently added vectorized math functions > > for GCN in Newlib. The -fno-math-errno flag is required in addition to > > the usual vectorization optimization flags for this to occur, and some > > of the math functions (the larger double-precision ones) require a large > > stack size to function properly. > > > > This patch requires the GCN vector math functions in Newlib to function > > - these were included in the recent 4.3.0.20230120 snapshot. As this was > > a minimum requirement starting from the patch 'amdgcn, libgomp: Manually > > allocated stacks', this should not be a problem. > > > > I have added new testcases in the testsuite that compare the output of > > the vectorized math functions against the scalar, passing if they are > > sufficiently close. With the testcase for standalone GCN (without > > libgomp) in gcc.target/gcn/, there is a problem since gcn-run currently > > cannot set the stack size correctly in DejaGnu testing, so I have made > > it a compile test for now - it is still useful to check that calls to > > the correct functions are being made. The runtime correctness is still > > covered by the libgomp test. > > I thought we were moving towards using the simd attribute instead and > moving away from these kind of patches. > Though since gcn is a special target that including math.h normally > does not happen for offloading this might be still usefull.
Yes, this particular target hook is considered legacy. See how for example glibc provides a math-vector-fortran.h file announcing them to the fortran compiler in case you were wondering how to target non-C family frontends. Richard. > > > > > Okay for trunk? > > We are in stage 4 of GCC 13 release cycle, I suspect we want to wait > until GCC 13 branches off to apply this. > > Thanks, > Andrew Pinski > > > > > Thanks > > > > Kwok
