Re: Should we import gnulib under gcc/ or at the top-level like libiberty?
On 11 July 2016 at 14:40, Ian Lance Taylor wrote: > On Sun, Jul 10, 2016 at 10:15 AM, Manuel López-Ibáñez > wrote: >> On 23 June 2016 at 18:02, Pedro Alves wrote: >>> But on the other hand, the idea of maintaining multiple gnulib >>> copies isn't that appealing either. Considering that the long >>> term desired result ends up with a libiberty that is no longer a >>> portability library, but instead only an utilities library, then to >>> get to that stage, the other programs in the binutils-gdb repo which >>> rely on libiberty too, binutils proper, gas, ld, gold, etc., need >>> to be converted to use gnulib as well. And then a single >>> gnulib sounds even more appealing. >> >> AFAICT, the only "utilities" found in libiberty not appropriate for >> gnulib is the demangler. That would be more appropriate for a >> libdemangler library shared among all gnutools. > > Does gnulib have a functional equivalent to the pex and simple-object > mini-libraries? I don't really know. Part of the GSoC project is to figure out the answer to such questions. In any case, the main goal of the GSoC is to start using gnulib, so that next time we need something not provided by libiberty we can simply import it from gnulib rather than having to implement it ourselves or manually import it into libiberty and keep it in sync. Cheers, Manuel.
RE: [RFC] Rationale for passing vectors by value in SIMD registers
Andrew Pinski writes: > On Sat, Feb 15, 2014 at 12:16 AM, Matthew Fortune > wrote: > >> On Fri, Feb 14, 2014 at 2:17 AM, Matthew Fortune > >> wrote: > >> > MIPS is currently evaluating the benefit of using SIMD registers to pass > >> vector data by value. It is currently unclear how important it is for > >> vector data > >> to be passed in SIMD registers. I.e. the need for passing vector data by > >> value > >> in real world code is not immediately obvious. The performance advantage is > >> therefore also unclear. > >> > > >> > Can anyone offer insight in the rationale behind decision decisions made > >> for other architectures ABIs? For example, the x86 and x86_64 calling > >> convention for vector data types presumes that they will passed in SSE/AVX > >> registers and raises warnings if passed when sse/avx support is not > >> enabled. > >> This is what MIPS is currently considering however there are two concerns: > >> > > >> > 1) What about the ability to create architecture/implementation > >> independent APIs that may include vector types in the prototypes. Such APIs > >> may be built for varying levels of hardware support to make the most of a > >> specific architecture implementation but be called from otherwise > >> implementation agnostic code. To support such a scenario we would need to > >> use a common calling convention usable on all architecture variants. > >> > 2) Although vector types are not specifically covered by existing ABI > >> definitions for MIPS we have unfortunately got a defacto standard for how > >> to pass these by value. Vector types are simply considered to be small > >> structures and passed as such following normal ABI rules. This is still a > >> concern even though it is generally accepted that there is some room for > >> change when it comes to vector data types in an existing ABI. > >> > > >> > If anyone could offer a brief history the x86 ABI with respect to vector > >> > data > >> types that may also be interesting. One question would be whether the use > >> of vector registers in the calling convention was only enabled by default > >> once > >> there was a critical mass of implementations, and therefore the default ABI > >> was changed to start making assumptions about the availability of features > >> like SSE and AVX. > >> > > >> > Comments from any other architecture that has had to make such changes > >> over time would also be welcome. > >> > >> PPC and arm and AARCH64 are common targets where vectors are > >> passed/return via value. The idea is simple, sometimes you have functions > >> like vector float vsinf(vector float a) where you want to be faster and > >> avoid a > >> round trip to L1 (or even L2). These kind of functions are common for > >> vector > >> programming. That is extending the scalar versions to the vector versions. > > > > I suppose this cost (L1/L2) is mitigated to some extent if the base ABI > > were to pass a > vector in multiple GP/FP register rather than via the stack. There would of > course still > be a cost to marshall the data between GP/FP and SIMD registers. For such a > support > routine like vsinf I would expect it also needs a reduced clobber set to > ensure that the > caller's live SIMD registers don't need saving/restoring, such registers > would normally be > caller-saved. If the routine were to clobber all SIMD registers anyway then > the > improvement in argument passing seems negligible. > > > > Do you/anyone know of any open source projects, which have started adopting > > generic > vector types, and show the use of this kind of construct? > > Yes glibc provides these functions on x86 now. Wow, old thread you must have a good memory! I saw libmvec go in some time ago, I guess you are referring to that or is there something else now (I'm out of date with glibc development)? I am hoping to steer MIPS towards supporting passing vectors by value via a an ABI extension that is opt-in rather than default. The main reason is the range of competing vector extensions whether defined as official ASEs or core specific. I think we can still get vectors passed by value with the only extra requirement being that a prototype would need a calling convention attribute. Thanks, Matthew
gcc-7-20160717 is now available
Snapshot gcc-7-20160717 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20160717/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 238420 You'll find: gcc-7-20160717.tar.bz2 Complete GCC MD5=353cf3402df6fdc9b007f5a44d1133c1 SHA1=779a439ad6270d4dfac16c1205ab22688011d033 Diffs from 7-20160710 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
