Re: [PING] [PR other/70945] Handle function_glibc_finite_math in offloading

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jun 08, 2016 at 03:47:54PM +0200, Thomas Schwinge wrote:
> > I'm not saying newlib in general, let newlib do whatever they want, but
> > I'm talking about offloading port(s) of newlib, which IMHO should provide
> > translation layer from the host headers to the offloading target functions.
> 
> In earlier emails I argued against this, and you didn't reject it back
> then.  So you're saying that we'll need a compatibility/translation layer
> for any kind of target libc that people may be using (which arguably is
> glibc primarily, but do we intend to limit us to that?), and keep that
> maintained as these target libcs evolve?

Yes, to me that looks simplest.

> > The thing is, I think it is much better to have this layer in a source form
> > where you can easily modify it than inside of the compiler where you have to
> > hardwire everything in there.  It could sit in some offloading directory of
> > newlib, which the offloading port(s) could share.
> 
> I argue this should be as close as possible to the origin, which is the
> glibc header files, and as these are not feasible to be adjusted quickly,
> we instead do it in the compilation process, for now.

For one, I don't understand the argument about hard upgrades of the libc
headers, upgrading libc isn't much harder than updating the compiler, and
you have always the possibility to fixinclude the headers or whatever else.

But, I'm also not convinced how would you like to change the headers.
The finite math entrypoints are just one example of many things you can do
in libc headers, asm redirects to another entrypoint, so you'd need some way
to say, and if offloading to target XYZ (e.g. I think for XeonPhi that is
not needed), redirect to this instead.  Consider the various glibc macros or
inlines, e.g. for -D_FORTIFY_SOURCE*, or optimized string.h in
bits/string2.h, you can end up with various macros for standard functions,
I really don't think it would be easy to somehow undo those changes except
for providing a compatibility layer in the offloading library.
Whether through some special markup in libc headers or (much worse)
hardwiring it all in the compiler.

Sure, we should document what APIs we are willing to support, but then
adding a compat layer shouldn't be that hard.

> > The __*_finite functions aren't the only one, what if glibc the next half a
> > year adds another 4-5 of the finite math functions?
> 
> Huh?  In your proposed model I would then have to react to that, and
> alter the translation layer, whereas in my model it would just continue
> to work?

No, in your model you'd need to update the compiler to hardwire further
stuff in it.

	Jakub