More methods of reducing the register pressure
Hello All: To reduce the register pressure, I am proposing the following methods of reducing the registers. 1. Assigning same registers or sharing same register for the logical registers having the same value. To determine the logical registers having the same value is the real challenge. Is there is any way in GCC to determine the logical registers having the same value? 2. For the architecture with the self-modifying instructions the DEF-USE will not overlap and can Do the better register allocator and thus reclaiming the registers when it's no longer used. Such self-modifying instructions can assign the same registers. For example: OP R1 -Definition. ... . ... No used. OP R1,R1 self-modifying. . . .. Not Used OP R1, R1 Self-modifying. To reduce the registers pressure such cases with self-modifying instructions with the architecture Support will not overlap as the use is done after it's defined. And also the USE will be after the DEF Making the life time as not overlap and can assign the same registers. Such cases needs to be handled separately for the better register pressure usage. Thoughts Please? Thanks & Regards Ajit
Re: NIOS and atomic primitives
On 04/18/2015 09:06 PM, Sandra Loosemore wrote: On 04/18/2015 07:35 PM, Joel Sherrill wrote: Hi with nios2-rtems on gcc 4.9.2, we are getting undefineds for some atomic primitives. Are these implemented or is some magic bit of configurery missing for nios-rtems? __sync_fetch_and_add_4 is missing on a simple C++ IO streams sanity test. libgcc presently only provides these functions on nios2-*-linux* and does not have any configury for nios2-*-rtems. I think you are on your own here Chung-Lin and I are only set up for GCC testing on nios2-elf and nios2-linux-gnu and cannot really support RTEMS. No worries. libgcc and RTEMS have a cursed relationship. :) Is it one of the standard g++ or libstdc++ test cases that is failing? I could check what nios2-elf does with it if I knew what to look for. I spotted this in one of our own simple C++ sanity checks. I actually don't have any way to run nios2 and rely on the RTEMS community for testing. For core gcc issues, your testing on nios2-elf is more than sufficient to keep code issues at bay for us. RTEMS targets are just a few tweaks away from it. Thanks for the offer but just knowing it is supported and a libgcc configure issue is more than enough to fix this and submit a patch. -Sandra -- -- Joel Sherrill Ask me about RTEMS: a free RTOS Support and Training Available
April GNU Toolchain Update
Hi Guys, This is an experimental posting of an extended version of my gcc blog. Every month I post an update covering changes in gcc, the binutils, newlib, and gdb here: http://nickclifton.livejournal.com/ It was suggested that readers of this mailing list might be interested in the information too, so I am posting this trial run. If you hate it, please let me know and I will stop. If you like then please also let me know and I will continue. If you find mistakes or omissions, then I will not be surprised, but I will be very glad to hear them. The blog itself came about because every month I perform a merge between the public FSF sources and Red Hat's internal, development sources. During the course of this merge I often find out about changes and updates that I had not even realised had happened. I also try to keep track of how well different targets are building and performing in order to get an overall feel for the state of the sources. Cheers Nick --- There are several things to report this month: * The GCC version 5 branch has been created. No releases have been made from this branch yet, but when one happens it will be GCC 5.1. Meanwhile the mainline development sources have been switched to calling themselves GCC version 6. * Support has been added for configuring targets that use the Nuxi CloudABI. More details of this ABI can be found here: https://github.com/NuxiNL/cloudlibc * The linker and assembler now support an option to control how DWARF debug sections are compressed: --compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi] Selecting NONE disables compression. This is the default behaviour if this option is not used. Selecting ZLIB or ZLIB-GNU compresses the sections and then renames them to start with a .z. This is the old method of indicating that a debug section has been compressed. Selecting ZLIB-GABI compresses the sections, but rather than renaming them they instead have the new SHF_COMPRESSED bit set in their ELF section header. The other binutils tools have been updated to recognise and handle this SHF_COMPRESSED bit. More information on the new bit can be found here: https://groups.google.com/forum/#!msg/generic-abi/dBOS1H47Q64/PaJvELtaJrsJ In another, related change, the binutils will no longer compress a debug section if doing so would actually make it bigger. Also the zlib compression/decompression library sources have now been brought in to the binutils git repository and are now a standard part of a binutils release. * The linker has a new command line option: --warn-orphan This option tells the linker to generate a warning message whenever it has to guess at the placement of a section in the output file. This happens when the linker script in use does not specify where the section should go. * The compiler has a new option: -fsanitize-sections=sec1,sec2,... This tells the address sanitizer to add protection to global variables defined in the named section(s). By default any globals in sections with user defined names are not sanitized as the compiler does not know what is going to happen to them. In particular variables in such sections sometimes end up being merged into an array of values, where the presence of address sanitization markers would break the array. * The AVR port of the compiler has a new command line option: -nodevicelib This tells the compiler not to link against AVR-LibC's device specific library libdev.a. * The RX port of GCC has a new command line option to disable the use of RX string instructions (SMOVF, SUNTIL, etc). This matters because it is unsafe to use these instructions if the program might access the I/O portion of the address space. * The RL78 port of GCC now has support the multiply and divide instructions provided by the G14 cpu, and the divide hardware peripheral provided by the G13 core. * GDB now honours the content of the file /proc/PID/coredump_filter (PID is the process ID) on GNU/Linux systems. This file can be used to specify the types of memory mappings that will be included in a corefile. For more information, please refer to the manual page of "core(5)". GDB also has a new command: "set use-coredump-filter on|off". It allows to set whether GDB will read the content of the /proc/PID/coredump_filter file when generating a corefile. * GDB's "info os cpus" command on GNU/Linux can now display information on the cpus/cores on the system. * GDB has two new commands: "set serial parity odd|even|none" and "show serial parity". These allows to set or show parity for the remote serial I/O. Che
Re: More methods of reducing the register pressure
On 04/19/2015 09:28 AM, Ajit Kumar Agarwal wrote: Hello All: To reduce the register pressure, I am proposing the following methods of reducing the registers. 1. Assigning same registers or sharing same register for the logical registers having the same value. To determine the logical registers having the same value is the real challenge. Is there is any way in GCC to determine the logical registers having the same value? I believe Vlad looked at this 10+ years ago and it was of marginal/no real benefit. 2. For the architecture with the self-modifying instructions the DEF-USE will not overlap and can Do the better register allocator and thus reclaiming the registers when it's no longer used. Such self-modifying instructions can assign the same registers. For example: OP R1 -Definition. ... . ... No used. OP R1,R1 self-modifying. . . .. Not Used OP R1, R1 Self-modifying. I would think this would be handled by the normal life & conflict analysis which works on pseudos. jeff
Re: More methods of reducing the register pressure
On 19/04/15 01:11 PM, Jeff Law wrote: On 04/19/2015 09:28 AM, Ajit Kumar Agarwal wrote: Hello All: To reduce the register pressure, I am proposing the following methods of reducing the registers. 1. Assigning same registers or sharing same register for the logical registers having the same value. To determine the logical registers having the same value is the real challenge. Is there is any way in GCC to determine the logical registers having the same value? I believe Vlad looked at this 10+ years ago and it was of marginal/no real benefit. Right, Jeff. Results of using GVN for building conflict graph was described in article: ftp://ftp.gwdg.de/pub/misc/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
Re: More methods of reducing the register pressure
On 19/04/15 11:28 AM, Ajit Kumar Agarwal wrote: Hello All: To reduce the register pressure, I am proposing the following methods of reducing the registers. 1. Assigning same registers or sharing same register for the logical registers having the same value. To determine the logical registers having the same value is the real challenge. Is there is any way in GCC to determine the logical registers having the same value? I believe you propose to use GVN for building conflict graphs. I've tried long ago for old RA and it gave tiny improvement for few SPEC2000 tests but significant compiler slow down. BTW, LRA uses values (see member val for reg_info) in very local scope to remove some conflicts. The reason for adding this was specific LRA transformations for reloading which created unnecessary conflicts in plenty cases. 2. For the architecture with the self-modifying instructions the DEF-USE will not overlap and can Do the better register allocator and thus reclaiming the registers when it's no longer used. Such self-modifying instructions can assign the same registers. For example: OP R1 -Definition. ... . ... No used. OP R1,R1 self-modifying. . . .. Not Used OP R1, R1 Self-modifying. To reduce the registers pressure such cases with self-modifying instructions with the architecture Support will not overlap as the use is done after it's defined. And also the USE will be after the DEF Making the life time as not overlap and can assign the same registers. IRA creates small cost preferences for died input operand/output operands of the same insn. This preferences are processed by general technique as other preferences and result in assigning the same hard register in many cases. It is done taking overall RA picture into account. IMHO, implementing it as a separate pass would create more harm than benefits, as it makes pseudo live range longer and in some cases prohibits live-range splitting (when we use different pseudos) at natural program points for splitting. I even would say that if insn contains the same pseudo as input and output we should do register renaming to create a point for potential live range splitting (and actually register renaming -fweb in GCC is profitable even for 2-op insns). If there is a possibility and benefit to use the same hard register, the preference mentioned above will guide IRA to use the same hard reg. Such cases needs to be handled separately for the better register pressure usage. Thoughts Please? Thanks & Regards Ajit
Re: Connecting to gcc.gnu.org - keygen_fail
On Tue, 14 Apr 2015, Mikhail Maltsev wrote:
> The server replies with status code "307 Temporary Redirect" and
> redirects to HTTPS version ("Location:
> https://gcc.gnu.org/bugs/segfault.html";). Recent versions of Chrome and
> Firefox (well, Iceweasel actually) handle it correctly. SSL certificate
> is OK.
>
> Though it's strange. Why not "301 Moved Permanently"?...
This is a good point. Let's see what we can do about this.
Gerald
gcc-6-20150419 is now available
Snapshot gcc-6-20150419 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20150419/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 22 You'll find: gcc-6-20150419.tar.bz2 Complete GCC MD5=5abcd2dadff77791d732caf5934f49a5 SHA1=5544e79c0aa55fac7d6ae3d38558a7ad45605dcf Diffs from 6-20150412 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 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.
