Hi!
On Tue, 7 Jun 2016 08:54:10 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Jun 06, 2016 at 09:11:18PM +0000, Joseph Myers wrote:
> > On Fri, 3 Jun 2016, Jakub Jelinek wrote:
> > > I think it would be better to just add this support to newlib.
> >
> > That suggestion doesn't really make sense to me. Why should newlib be
> > expected to follow the same choices as glibc regarding what variants of
> > libm functions to export, beyond the standard names for those functions,
> > or how to name any variants it does export?
ACK. I'm thinking somewhat along the lines that in GCC's offloading
compilation, the target ("host") side should "sanitize" the code
presented to the offloading compilers. One first step for that I have
presented here, to sanitize the finite math functions that get
special-cased by glibc.
A next step is to define the set of external functions/symbols that are
permitted to be used in offloaded code, and then sanitize these at the
glibc header file level, for example, by adding (new) attributes, and
similar.
> 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?
> 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.
As I understand Joseph's point, similar handling will be required for
vector function variants anyway.
> 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?
> What about e.g.
> -D_FORTIFY_SOURCE=2 string functions, etc.?
Obviously, these will required similar handling. I specifically said:
"The first thing I'm working on is math functions usage in offloaded
regions".
Grüße
Thomas
