On Tue, Jan 17, 2017 at 12:31:05PM -0500, Carlos O'Donell wrote: > On 01/09/2017 08:18 PM, Richard W.M. Jones wrote: > > On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote: > >> On Sat, Jan 07, 2017 at 11:15:28PM +0000, Richard W.M. Jones wrote: > >>> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: > >>>> On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote: > >>>>> Two suggestions were raised as alternatives to the container approach: > >>>>> > >>>>> * Switch to using the Debian style of multi-arch layout, which instead of > >>>>> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this would > >>>>> include the emergence of a de-facto standard for system layout between the major > >>>>> distributions. > >>>> > >>>> Isn't this just result of good marketing of "multi-arch" distros? Because > >>>> I fail to see where that approach is superior compared to what we have. > >>> > >>> Partly because there exist more than 2 architectures (think: > >>> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various > >> > >> Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes > >> for */lib<suffix> is able to deal with more than 2 multilibs, e.g. MIPS has > >> 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate > >> multilib, those are just optimizations you can do in the same multilib, that > >> can and should be resolved either completely inside of libraries that want > >> to have optimized parts (using IFUNC, target_clones, ...) > > > > I should note that RV64G vs RV64GC (compressed) is not something that > > could be handled by ifuncs. It's a deep change that affects all the > > generated code. I'm hoping that every other RISC-V extension _can_ be > > handled only using ifuncs/target_clones etc. > > Could you clarify why IFUNC doesn't work? RISC-V normally uses a fixed size 32 bit encoding for every instruction*. The compressed extension (C) allows you to substitute 16 bit encodings for a limited subset of instructions. You would do this throughout all of your binaries and libraries (kernel too), so ifunc just isn't applicable. It's also beneficial to do this because it will reduce i-cache pressure and code size generally. At present it's unclear if real hardware will use RV64G or RV64GC or there will be a mixture of the two. If all real hardware uses RV64GC then IMHO we should just use compressed everywhere as part of our base requirements and the problem goes away. If RV64GC is uncommon, we'd ignore it and again it's not a problem. The problem arises if there is hardware falling in both camps and we want to support all of it optimally, in which case we'd probably need two builds of Fedora or some sort of advanced multiarch support. Rich. * Except when it doesn't -- some extensions will be allowed to use two or more adjacent 32 bit words to encode a single instruction, but we can ignore those here. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
