Bernd Schmidt <bschm...@redhat.com> writes: > On 11/09/2015 11:24 AM, Richard Sandiford wrote: >> Bernd Schmidt <bschm...@redhat.com> writes: >>> I see it's already acked, but have you considered just doing away with >>> the builtin/internal function distinction? >> >> I think they're too different to be done away with entirely. built-in >> functions map directly to a specific C-level callable function and >> must have an fndecl, whereas no internal function should have an fndecl. >> Whether a built-in function is available depends on the selected >> language and what declarations the front-end has seen, while whether >> an internal function is available depends entirely on GCC internal >> information. > > Yes... but aren't these things fixable relatively easily (compared with > what your patches are doing)?
I'm not sure what you mean by "fix" though. I don't think we can change any of the constraints above. > I also have the problem that I can't quite see where your patch series > is going. Let's take "Add internal bitcount functions", it adds new > internal functions but no users AFAICS. What is the end goal here (there > doesn't seem to be a [0/N] description in my inbox)? The main goal is to allow functions to be vectorised simply by defining the associated optab. At the moment you can get a scalar square root instruction simply by defining something like sqrtdf2. But if you want to have vectorised sqrt, you need to have a target-specific C-level built-in function for the vector form of sqrt, implement TARGET_BUILTIN_VECTORIZED_FUNCTION, and expand the sqrt in the same way that the target expands other directly-called built-in functions. That seems unnecessarily indirect, especially when in practice those target-specific functions tend to use patterns like sqrtv2df2 anyway. It seems better to have GCC use the vector optabs directly. This was prompted by the patch Dave Sherwood posted to support scalar and vector fmin() and fmax() even with -fno-fast-math on aarch64. As things stood we needed the same approach: use an optab for the scalar version and TARGET_BUILTIN_VECTORIZED_FUNCTION for the vector version. The problem is that at present there's no aarch64 built-in function that does what we want, so we'd have to define a new one. And that seems silly when GCC really ought to be able to use the vector version of the optab without any more help from the target. I'm hoping to post those patches later today. But the series has other side-benefits, like: - allowing genmatch to fold calls to internal functions - splitting the computational part of maths function from the the fallback errno handling at an earlier point, so that they get more optimisation - clearly separating out the call folds that we're prepared to do on gimple, rather than calling into builtins.c. Thanks, Richard
