GNU Tools Cauldron 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, We are very pleased to invite you all to the GNU Tools Cauldron on 7-9 September 2018. Our venue this year is Manchester, UK. Details are here: https://gcc.gnu.org/wiki/cauldron2018 As usual, please register, send abstracts and ask administrivia questions to tools-cauldron-admin AT googlegroups.com. The Cauldron is organized by a small ad hoc group of volunteers. We are keen to add some more people, so others can stand down. If you'd like to be part of that organizing committee, please email the same address. I have sent this announcement to the main GCC, GDB, binutils, CGEN, DejaGnu, newlib and glibc mailing lists. Please feel free to share with any other groups that are appropriate. We look forward to seeing you in Manchester in September. Jeremy - -- Tel: +44 (1590) 610184 Cell:+44 (7970) 676050 SkypeID: jeremybennett Twitter: @jeremypbennett Email: jeremy.benn...@embecosm.com Web: www.embecosm.com PGP key: 1024D/BEF58172FB4754E1 2009-03-20 -BEGIN PGP SIGNATURE- iGMEARECACMFAlqQS4scHGplcmVteS5iZW5uZXR0QGVtYmVjb3NtLmNvbQAKCRC+ 9YFy+0dU4SvxAJ9DyLkDPxiHJAmvB8vn7GwQbDs32ACggJm7nm25SVJNDtgOpEsL uHawDK8= =f9gt -END PGP SIGNATURE-
Re: $target.h vs $target-protos.h
Joseph Myers writes: > On Mon, 19 Feb 2018, Sandra Loosemore wrote: > >> On 02/19/2018 09:45 AM, Joseph Myers wrote: >> > On Sun, 18 Feb 2018, Sandra Loosemore wrote: >> > >> > > Thanks, this makes sense. I think I could produce a documentation patch >> > > that >> > > explains that the difference is early vs late inclusion, and explains >> > > that >> > > any >> > > declarations involving tree or rtx types must go in $target-protos.h >> > > because >> > > those types are not defined when $target.h is included. >> > >> > That's not the case now for tree or rtx types, since they're (forward) >> > declared in coretypes.h. It may still be the case for some types, but not >> > those. >> >> OK, I think I misunderstood your previous message -- it's the >> machine_mode-related types that have the circular dependency, but rtx and >> tree >> no longer do. Is that right? > > The machine_mode-related types don't either (since coretypes.h includes > insn-modes.h and machmode.h). Some types may well still have that > dependency, but I don't know which. The main one I remember is rtx_code, but that can only be used in $target-protos.h when RTX_CODE is defined. Richard
Vectorization / libmvec / libgomp question
I have a question about loop vectorization, OpenMP, and libmvec. I am experimenting with this on Aarch64 and looking at what exists on x86 and trying to understand the relationship (if there is one) between the vector library (libmvec) and OpenMP (libgomp). On x86, an OpenMP loop with a sin() call will call a function whose name is defined by the OpenMP x86 ABI (_ZGVbN2v_sin) but if I just vectorize a normal, non-OpenMP loop containing a sin() call and specify '-mveclibabi=[svml|acml]' then I get a call to some thing else (vmldSin2 or __vrd2_sin). If I do not specify '-mveclibabi' then a loop with a sin() in it doesn't get vectorized at all. On Aarch64, where there is no existing vector library (at least not one recognized by GCC), what do I want to do? Obviously, for OpenMP, I would call the name specified by an Aarch64 OpenMP ABI (not yet publicly defined). It would be something like '_ZGVbN2v_sin'. But what about the case of a vectorized loop that does not use OpenMP. Is it reasonable (desirable?) in that case to call the OpenMP routine (_ZGVbN2v_sin) that is defined in libgomp or should I call a different routine with a different name that is in libmvec? Or should I put '_ZGVbN2v_sin' in libmvec and have libgomp be dependent on libmvec? Do I need a -mveclibabi flag for GCC if there is only one vector ABI for Aarch64? I might still want to control whether vector functions are called while vectorizing a loop in the absense of OpenMP. Steve Ellcey sell...@cavium.com
Re: Vectorization / libmvec / libgomp question
On Fri, Feb 23, 2018 at 11:44:40AM -0800, Steve Ellcey wrote: > I have a question about loop vectorization, OpenMP, and libmvec. I am > experimenting with this on Aarch64 and looking at what exists on x86 > and trying to understand the relationship (if there is one) between the > vector library (libmvec) and OpenMP (libgomp). There is no connection to libgomp, just to OpenMP #pragma omp declare simd, which is now also available using the simd attribute in GCC in a simplified way. Neither #pragma omp simd nor #pragma omp declare simd need any library support, the former just expresses strong desire to vectorize the loop, some guarantees about it and perhaps some further details on variable behavior. #pragma omp declare simd is a way to require multiple entry-points of a function, scalar and one or more vector versions on definitions, or assume definition is accompanied by those extra versions. If you don't have any preexisting vectorized library, I'd suggest to follow what libmvec does and use the simd attribute. A precondition is to define an ABI and mangling. For mangling on Intel GCC uses modified https://software.intel.com/sites/default/files/managed/b4/c8/Intel-Vector-Function-ABI.pdf mangling, instead of the x/y/Y/z/Z letters we use b/c/d/e letters and don't use __regcall underlying calling convention, just normal calling conventions. For AArch64, dunno if you want to define one style for pre-SVE and another one for SVE or even have multiple versions of the former or latter. After designing it, config/aarch64/ needs to implement the simd_clone_compute_vecsize_and_simdlen target hook, and once this is done, you can implement the library, either in assembly or in C code using the simd attribute or #pragma omp declare simd. Jakub
