Re: RISC-V ELF multilibs
On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote: On 05/26/2018 06:04 AM, Sebastian Huber wrote: Why is the default multilib and a variant identical? This is supposed to be a single multilib, with two names. We use MULTILIB_REUSE to map the two names to a single multilib. rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc ./rv64imafdc/lp64d/libgcc.a rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc ./rv64imafdc/lp64d/libgcc.a rohan:1032$ ./xgcc -B./ --print-libgcc ./libgcc.a rohan:1033$ So this is working right when the -march option is given, but not when no -march is given. I'd suggest a bug report so I can track this, if you haven't already filed one. IIRC this is actually a limit of the GCC build system: there needs to be some default multilib, and it has to be unprefixed. I wanted to keep the library paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at /lib), so I chose to just build a redundant multilib. It'd be great to get rid of this, but I'm afraid it's way past my level of understanding as to how all this works. Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? The expectation is that most implementations will include the C extension. It reduces code size, improves performance, and I think I read somewhere that it takes only 400 gates to implement. It isn't practical to try to support every possible combination of architecture and ABI here, as there are too many possible combinations. But if there is a major RISC-V target that is rv32g or rv64g then we should consider it. You can of course define your own set of multilibs. While that's the standard answer, note that Sebastian added the RISC-V RTEMS target in the first place so as far as I'm concerned he can add additional multilibs to it if he wants. While I'm not opposed to RTEMS multilibs for rv32g/ilp32d and rv64g/lp64d, note that we have made the decision in Linux land that the C extension will be common and thus I expect most RISC-V implementations with virtual memory to also have the C extension. If you go down this route then you should move RTEMS to its own multilib target fragment (t-rtems-multilib or something similar). If you need help figuring out the patch feel free to ask. I wrote a blog that might be useful https://www.sifive.com/blog/2017/09/18/all-aboard-part-5-risc-v-multilib/
Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP
(Missed this thread initially due to incorrect email address) > On 29 May 2018, at 11:05, Richard Sandiford > wrote: > > Jeff Law writes: >> Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff. >> When we left things I think we were trying to decide between >> CLOBBER_HIGH and clobbering the appropriate subreg. The problem with >> the latter is the dataflow we compute is inaccurate (overly pessimistic) >> so that'd have to be fixed. Yes, I want to get back to looking at this again, however I’ve been busy elsewhere. > > The clobbered part of the register in this case is a high-part subreg, > which is ill-formed for single registers. It would also be difficult > to represent in terms of the mode, since there are no defined modes for > what can be stored in the high part of an SVE register. For 128-bit > SVE that mode would have zero bits. :-) > > I thought the alternative suggestion was instead to have: > > (set (reg:M X) (reg:M X)) > > when X is preserved in mode M but not in wider modes. But that seems > like too much of a special case to me, both in terms of the source and > the destination: Agreed. When I looked at doing it that way back in Jan, my conclusion was that if we did it that way we end up with more or less the same code but instead of: if (GET_CODE (setter) == CLOBBER_HIGH && reg_is_clobbered_by_clobber_high(REGNO(dest), GET_MODE (rsp->last_set_value)) Now becomes something like: if (GET_CODE (setter) == SET && REG_P (dest) && HARD_REGISTER_P (dest) && REG_P (src) && REGNO(dst) == REGNO(src) && reg_is_clobbered_by_self_set(REGNO(dest), GET_MODE (rsp->last_set_value)) Ok, some of that code can go into a macro, but it feel much clearer to explicitly check for CLOBBER_HIGH rather then applying some special semantics to a specific SET case. Alan.
Re: Enabling -ftree-slp-vectorize on -O2/Os
Okay, I think I can withdraw the suggestion. It is apparently not providing a stable end performance. I would like to end with sharing the measurements I made that motivated me to suggest the change. Hopefully it can be useful if tree-slp-vectorize gets improved and the suggestion comes up again. As I said previously, the benchmarks I ran were not affected, probably because most thing we benchmark in Qt often is hand-optimized already, but the binary size with tree-slp-vectorize was on average a one or two percent smaller, though was not universal, and many smaller libraries were unaffected. gcc-8 version 8.1.0 (Debian 8.1.0-4) gcc-7 version 7.3.0 (Debian 7.3.0-19) Qt version 5.11.0 (edited to override selective use of -O3) size library g++-7 -march=corei7 -O2 8015632 libQt5Widgets.so.5.11.0 6194288 libQt5Gui.so.5.11.0 760016 libQt5DBus.so.5.11.0 5603160 libQt5Core.so.5.11.0 g++-7 -march=corei7 -O2 -ftree-slp-vectorize 8007440 libQt5Widgets.so.5.11.0 6182000 libQt5Gui.so.5.11.0 760016 libQt5DBus.so.5.11.0 5603224 libQt5Core.so.5.11.0 g++-8 -O2 8062520 libQt5Widgets.so.5.11.0 6232160 libQt5Gui.so.5.11.0 765584 libQt5DBus.so.5.11.0 5848528 libQt5Core.so.5.11.0 g++-8 -O2 -ftree-slp-vectorize 8058424 libQt5Widgets.so.5.11.0 6219872 libQt5Gui.so.5.11.0 769680 libQt5DBus.so.5.11.0 5844560 libQt5Core.so.5.11.0 g++-8 -march=corei7 -O2 8062520 libQt5Widgets.so.5.11.0 6215584 libQt5Gui.so.5.11.0 765584 libQt5DBus.so.5.11.0 580 libQt5Core.so.5.11.0 g++-8 -march=corei7 -O2 -ftree-slp-vectorize 8046136 libQt5Widgets.so.5.11.0 6191008 libQt5Gui.so.5.11.0 765584 libQt5DBus.so.5.11.0 5840472 libQt5Core.so.5.11.0 g++-8 -march=haswell -O2 8046136 libQt5Widgets.so.5.11.0 6170408 libQt5Gui.so.5.11.0 765584 libQt5DBus.so.5.11.0 5852448 libQt5Core.so.5.11.0 g++-8 -march=haswell -O2 -ftree-slp-vectorize 8046136 libQt5Widgets.so.5.11.0 6158120 libQt5Gui.so.5.11.0 765584 libQt5DBus.so.5.11.0 5848480 libQt5Core.so.5.11.0 g++-8 -march=haswell -Os 6990368 libQt5Widgets.so.5.11.0 5030616 libQt5Gui.so.5.11.0 624160 libQt5DBus.so.5.11.0 4847056 libQt5Core.so.5.11.0 g++-8 -march=haswell -Os -ftree-slp-vectorize 6986272 libQt5Widgets.so.5.11.0 5018328 libQt5Gui.so.5.11.0 624160 libQt5DBus.so.5.11.0 4847120 libQt5Core.so.5.11.0 g++-8 -march=haswell -Os -flto 6785760 libQt5Widgets.so.5.11.0 4844464 libQt5Gui.so.5.11.0 593488 libQt5DBus.so.5.11.0 4688432 libQt5Core.so.5.11.0 g++-8 -march=haswell -Os -flto -ftree-slp-vectorize 6777568 libQt5Widgets.so.5.11.0 4836272 libQt5Gui.so.5.11.0 593488 libQt5DBus.so.5.11.0 4688472 libQt5Core.so.5.11.0
RE: RISC-V ELF multilibs
Palmer Dabbelt writes: > On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote: > > On 05/26/2018 06:04 AM, Sebastian Huber wrote: > >> Why is the default multilib and a variant identical? > > > > This is supposed to be a single multilib, with two names. We use > > MULTILIB_REUSE to map the two names to a single multilib. > > > > rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc > > ./rv64imafdc/lp64d/libgcc.a > > rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc > > ./rv64imafdc/lp64d/libgcc.a > > rohan:1032$ ./xgcc -B./ --print-libgcc > > ./libgcc.a > > rohan:1033$ > > > > So this is working right when the -march option is given, but not > when > > no -march is given. I'd suggest a bug report so I can track this, if > > you haven't already filed one. > > IIRC this is actually a limit of the GCC build system: there needs to > be some > default multilib, and it has to be unprefixed. I wanted to keep the > library > paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at > /lib), > so I chose to just build a redundant multilib. > > It'd be great to get rid of this, but I'm afraid it's way past my level > of > understanding as to how all this works. I do actually have a solution for this but it is not submitted upstream. MIPS has basically the same set of problems that RISC-V does in this area and in an ideal world there would be no 'fallback' multilib such that if you use compiler options that map to a library variant that does not exist then the linker just fails to find any libraries at all rather than using the default multilib. I can share the raw patch for this and try to give you some idea about how it works. I am struggling to find time to do much open source support at the moment so may not be able to do all the due diligence to get it committed. Would you be willing to take a look and do some of the work to get it in tree? Matthew
Re: not computable at load time
On Tue, 29 May 2018, Richard Biener wrote: > The testcase dates back to some repository creation rev. (egcs?) and > I'm not sure we may compute the difference of addresses of structure > members. So that GCC accepts this is probably not required. Joseph > may have a definitive answer here. My model of constant expressions for GNU C says this sort of subtraction (of two address constants based on the same object or function address) is a symbolic difference constant expression, which should be accepted as constant in initializers as an extension; it should be folded like other offsetof-like constructs. That should not depend on whether the result gets converted to a type of different width. However, the result of converting an address constant pointer to an integer type is only expected to be a constant expression if the resulting type *is* the same width as pointers. -- Joseph S. Myers jos...@codesourcery.com
Re: Adding a libgcc file
On Tue, 29 May 2018, Paul Koning wrote: > Question about proper target maintainer procedures... > > The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's > really easy to tweak those files for HImode. And that works. > > Should I add the HI files to the libgcc directory, or under > config/pdp11? There's nothing target specific about them, though I > don't know of other targets that might want this. The existing mechanism for building libgcc functions for different types is LIBGCC2_UNITS_PER_WORD. That may be defined in target .h files (currently those in gcc/), and also via siditi-object.mk which is used to build certain conversion functions for multiple types. As I understand it, you want to build certain non-conversion functions for multiple type as well. There are a few libgcc/config files that do define LIBGCC2_UNITS_PER_WORD to 2 before defining some L_* macros and including libgcc2.c, in order to define HImode functions (libgcc2.h then deals with getting the functions appropriately named via the definitions of __NW and __NDW, and getting them to use the right types via definitions of Wtype etc.). So you could just add such a file to config/pdp11, or you could try to develop a more general mechanism for targets to select HImode functions they want built in libgcc and for the common build machinery then to build those functions (and then refactor how existing targets build such functions accordingly). -- Joseph S. Myers jos...@codesourcery.com
Re: Adding a libgcc file
> On May 31, 2018, at 12:35 PM, Joseph Myers wrote: > > On Tue, 29 May 2018, Paul Koning wrote: > >> Question about proper target maintainer procedures... >> >> The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's >> really easy to tweak those files for HImode. And that works. >> >> Should I add the HI files to the libgcc directory, or under >> config/pdp11? There's nothing target specific about them, though I >> don't know of other targets that might want this. > > The existing mechanism for building libgcc functions for different types > is LIBGCC2_UNITS_PER_WORD. That may be defined in target .h files > (currently those in gcc/), and also via siditi-object.mk which is used to > build certain conversion functions for multiple types. > > As I understand it, you want to build certain non-conversion functions for > multiple type as well. There are a few libgcc/config files that do define > LIBGCC2_UNITS_PER_WORD to 2 before defining some L_* macros and including > libgcc2.c, in order to define HImode functions (libgcc2.h then deals with > getting the functions appropriately named via the definitions of __NW and > __NDW, and getting them to use the right types via definitions of Wtype > etc.). > > So you could just add such a file to config/pdp11, or you could try to > develop a more general mechanism for targets to select HImode functions > they want built in libgcc and for the common build machinery then to build > those functions (and then refactor how existing targets build such > functions accordingly). I see udivdi in libgcc2.c, but udivsi is provided in separate file udivmod.c. That was introduced in 2001 by Rainer Orth. This code is used in three targets that I can see: cr16, iq2000, and pdp11. So it sounds like the cleaner answer is to generalize the libgcc2 code to provide the different length [u]div functions needed: DI for whoever uses it now, SI for those three, and HI for pdp11. I can give that a try, it's a more complex change but generality seems good. paul
Re: RISC-V ELF multilibs
On Thu, May 31, 2018 at 7:23 AM, Matthew Fortune wrote: > I do actually have a solution for this but it is not submitted upstream. > MIPS has basically the same set of problems that RISC-V does in this area > and in an ideal world there would be no 'fallback' multilib such that if > you use compiler options that map to a library variant that does not > exist then the linker just fails to find any libraries at all rather than > using the default multilib. > > I can share the raw patch for this and try to give you some idea about how > it works. I am struggling to find time to do much open source support at > the moment so may not be able to do all the due diligence to get it > committed. Would you be willing to take a look and do some of the work to > get it in tree? I have a long list of things on my to do list. RISC-V is a new target, and there is lots of stuff that needs to be bug fixed, finished, or added. I can't make any guarantees. But if you file a bug report and then attach a patch to it, someone might volunteer to help finish it. Or if it is too big to be reasonably attached to a bug report (like the nano mips work) you could put it on a branch, and mention the branch name as unfinished work in a bug report. Jim
gcc-7-20180531 is now available
Snapshot gcc-7-20180531 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180531/ 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/branches/gcc-7-branch revision 261044 You'll find: gcc-7-20180531.tar.xzComplete GCC SHA256=d2115e1a8be5c02f8426dff6035a1e4d74257f41597a04c6ab5a322c9dee9862 SHA1=e1c6c5cc8e4cae17182e25da778c4efa4f59d0ea Diffs from 7-20180524 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.
Re: RISC-V ELF multilibs
On 29/05/18 20:02, Jim Wilson wrote: Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? The expectation is that most implementations will include the C extension. It reduces code size, improves performance, and I think I read somewhere that it takes only 400 gates to implement. It isn't practical to try to support every possible combination of architecture and ABI here, as there are too many possible combinations. But if there is a major RISC-V target that is rv32g or rv64g then we should consider it. You can of course define your own set of multilibs. I am not a hardware developer, but I heard that the C extension is not easy to implement in out of order machines. For example: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017-157.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RISC-V ELF multilibs
On 31/05/18 11:08, Palmer Dabbelt wrote: On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote: On 05/26/2018 06:04 AM, Sebastian Huber wrote: Why is the default multilib and a variant identical? This is supposed to be a single multilib, with two names. We use MULTILIB_REUSE to map the two names to a single multilib. rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc ./rv64imafdc/lp64d/libgcc.a rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc ./rv64imafdc/lp64d/libgcc.a rohan:1032$ ./xgcc -B./ --print-libgcc ./libgcc.a rohan:1033$ So this is working right when the -march option is given, but not when no -march is given. I'd suggest a bug report so I can track this, if you haven't already filed one. IIRC this is actually a limit of the GCC build system: there needs to be some default multilib, and it has to be unprefixed. I wanted to keep the library paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at /lib), so I chose to just build a redundant multilib. It'd be great to get rid of this, but I'm afraid it's way past my level of understanding as to how all this works. Ok, I just wanted to know if this was intentional or some sort of a bug. Some way to disable the default multilib would be nice in general. Ending up with the default multilib usually indicates some build system misconfiguration. It is not easy for the average user to figure out what is going on especially on targets where the linker silently links ABI incompatible objects together. Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? The expectation is that most implementations will include the C extension. It reduces code size, improves performance, and I think I read somewhere that it takes only 400 gates to implement. It isn't practical to try to support every possible combination of architecture and ABI here, as there are too many possible combinations. But if there is a major RISC-V target that is rv32g or rv64g then we should consider it. You can of course define your own set of multilibs. While that's the standard answer, note that Sebastian added the RISC-V RTEMS target in the first place so as far as I'm concerned he can add additional multilibs to it if he wants. While I'm not opposed to RTEMS multilibs for rv32g/ilp32d and rv64g/lp64d, note that we have made the decision in Linux land that the C extension will be common and thus I expect most RISC-V implementations with virtual memory to also have the C extension. If you go down this route then you should move RTEMS to its own multilib target fragment (t-rtems-multilib or something similar). If you need help figuring out the patch feel free to ask. I wrote a blog that might be useful https://www.sifive.com/blog/2017/09/18/all-aboard-part-5-risc-v-multilib/ I will probably add a special multilib set for RTEMS. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
