From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128296 invoked by alias); 11 May 2018 21:01:22 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 125074 invoked by uid 89); 11 May 2018 21:01:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=Something X-HELO: relay1.mentorg.com Date: Fri, 11 May 2018 21:01:00 -0000 From: Joseph Myers To: Tulio Magno Quites Machado Filho CC: Subject: Re: [PATCH] Move declare_mgen_finite_alias definition In-Reply-To: <87k1saudzb.fsf@linux.ibm.com> Message-ID: References: <20180511193852.6721-1-tuliom@linux.ibm.com> <87k1saudzb.fsf@linux.ibm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-05/txt/msg00519.txt.bz2 On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote: > Anyway, let me elaborate: we created a new template that uses this macro > and the directory sysdeps/ieee754/ldbl-128ibm-compat/. What's that directory for? Defining float128 functions (why can't you make the float128 sysdeps directory do the right thing?)? Defining ibm128 functions (what's wrong with the ldbl-128ibm sysdeps directory?)? Something else? What other (existing) sysdeps directories for floating-point types would you propose to use in the sysdeps directory ordering? What format would long double have when compiling code in those directories? > We're using template techniques to provide the new symbols instead of what > was adopted with float128_private.h. We haven't replaced this header (yet?), > though. The redefinition of macros that float128_private.h does, reached a > limit and became too complex to deal with. It's true that I think float128_private.h should eventually be replaced with the ldbl-128 functions being set up to always provide the *f128 names and then conditionally provide the *l names as well as aliases (and parts of that could be done incrementally, e.g. explicitly using FLT128_* instead of LDBL_* constants in the ldbl-128 code). But I don't think the type-generic template system has anything to do with code that is not type-generic. > With these macros, we can reuse code without redeclaring macros with the name > of functions. We can also redefine them per float type and directory, e.g. > sysdeps/ieee754/ldbl-128ibm-compat/math-type-macros-float128.h. > > This is an example of a file, using a sister-macro. > sysdeps/ieee754/ldbl-128ibm-compat/e_acosf128.c: > #include > > #include "../float128/e_acosf128.c" > > #undef __acosl_finite > #undef __acosl > > declare_mgen_finite_alias2 (__ieee754_acos, __acos) I don't think that's a good approach - I don't think the type-generic template system should be used with code that is not type-generic. The libm_alias_* macros are intended for use in type-specific function implementations (they are currently for *public, once-per-type* aliases, rather than internal names or *once-per-format* implementation namespace exported aliases - but additional macros for internal names could be added in e.g. the case of float128_private.h removal, where you'd have e.g. __ieee754_acosf128 as an unconditional name, __ieee754_acosl as a name only if that format is the default long double and likewise exactly one of __acosl_finite and __acosf128_finite). The obvious starting point for binary128 long double support on powerpc64le would seem to me to be just to get the installed headers to arrange for calls to *l to be asm-redirected to call *f128. That doesn't quite work because (a) it's not namespace-clean and (b) there are a few obsolescent functions with no public *f128 names which shouldn't get such names, but are part of the *l API so need to be available for long double in the -mabi=ieeelongdouble case, so you may actually want to call new __*f128 names instead (so get libm_alias_float128* to define those, maybe with new macro variants as needed, and watching out for cases where __*f128 already exists but isn't what *f128 is aliased to). If you're instead using new *l symbol versions and new exported names for ibm128 functions (which seems to me to increase the number of exported symbols unnecessarily), much the same applies (except you also need to make ldbl-128ibm functions use libm_alias_ldouble because I skipped those functions as not relevant to my _FloatN/_FloatNx work). -- Joseph S. Myers joseph@codesourcery.com