Re: Why are GCC Internals not Specification Driven ?
On Tue, Dec 20, 2016 at 1:48 AM, DJ Delorie wrote: > > Seima Rao writes: >> Has gcc become proprietory/commercial ? > > By definition: no, yes. It's been this way since the beginning, and > hasn't changed in decades. > >> Or has it become illegal to publish specification models >> of gcc internals ? Does this make the product sell less ? > > This sounds like you're trying to start an argument, instead of asking a > simple question. It is certainly not illegal to publish our > specifications, and we certainly *do* publish many of our specifications > (have you read the internals manual? You don't say whether or not you > did, but that would be a key bit of information to have disclosed). > Whether the product "sells" or not is rarely a driving factor for our > project. Most of us work on it because we need it to work better for > our own purposes. > > If you have specific questions about our documentation or development > process, please ask them. Please do not ask vague, leading, and > emotionally loaded questions. RTL and Gimple are documented. Are they > documemented well? That depends on your needs. Are they documented as > well as they could be? Probably not, but good enough for us so far. > > And as always, if you want to improve the situation, by all means feel > free to volunteer to do so ;-) Got your point that GCC is more inclined as a reference then a specification driven technology. Sincerely, Seima Rao.
input address reload issue
Hi all, and best wishes for the happy new year! I'm porting a private 4.6 backend to GCC 6 and facing a reload issue and I would appreciate a little help to cope with it. The issue happens when reloading: (set (reg:QI 47 [ _9 ]) (mem:QI (plus:SI (reg/v/f:SI 68 [orig:51 in ] [51]) (const_int 1 [0x1]) My understanding is that IRA allocates hardregs to allocno which are replaced by the reload pass which generates new reloads or spills regs when needed, right? Here the IRA chooses a reg (named r2)which makes the mem address not legitimate. Is it valid to allocate a reg which makes non legitimate address? Assuming it is, my understanding is that the reload chooses a legitimate reg (named a0 here) and shall emit insns (in emit_reload_insns) to set a0 correctly (RELOAD_FOR_INPUT_ADDRESS). Right? So the insn: (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1)) is transformed into: (set (reg:SI 8 a0) (reg:SI 2 r2)) (set (reg:SI 8 a0) (const_int 1)) (set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0))) (set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0)) This "basic" transformation requires two reload regs, but only one is given/used/possible from the rl structure (in emit_reload_insns). So where does the issue comes from? The need for 2 reload regs, the transformation which is too "basic" and could be optimized to use only one reload reg, or any wrong/missing reload target hook? Thanks in advance. Aurélien
Re: input address reload issue
On 01/05/2017 09:18 AM, Aurelien Buhrig wrote: Hi all, and best wishes for the happy new year! I'm porting a private 4.6 backend to GCC 6 and facing a reload issue and I would appreciate a little help to cope with it. The issue happens when reloading: (set (reg:QI 47 [ _9 ]) (mem:QI (plus:SI (reg/v/f:SI 68 [orig:51 in ] [51]) (const_int 1 [0x1]) My understanding is that IRA allocates hardregs to allocno which are replaced by the reload pass which generates new reloads or spills regs when needed, right? Here the IRA chooses a reg (named r2)which makes the mem address not legitimate. Is it valid to allocate a reg which makes non legitimate address? Assuming it is, my understanding is that the reload chooses a legitimate reg (named a0 here) and shall emit insns (in emit_reload_insns) to set a0 correctly (RELOAD_FOR_INPUT_ADDRESS). Right? So the insn: (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1)) is transformed into: (set (reg:SI 8 a0) (reg:SI 2 r2)) (set (reg:SI 8 a0) (const_int 1)) (set (reg:SI 8 a0) (plus:SI (reg:SI 8 a0) (reg:SI 8 a0))) (set (reg:QI 0 r0) (mem:QI (reg:SI 8 a0)) This "basic" transformation requires two reload regs, but only one is given/used/possible from the rl structure (in emit_reload_insns). So where does the issue comes from? The need for 2 reload regs, the transformation which is too "basic" and could be optimized to use only one reload reg, or any wrong/missing reload target hook? Sounds like you need secondary or intermediate reloads. Alternately, convert your port to LRA. It probably will still require some work, but LRA (rather than reload) is where the team focuses their energy these days. jeff
Re: Worse code after bbro?
> On 01/04/2017 03:46 AM, Segher Boessenkool wrote: > >On Wed, Jan 04, 2017 at 10:05:49AM +0100, Richard Biener wrote: > >>>The code size is identical, but the trunk version executes one more > >>>instruction everytime the loop runs (explicit jump to .L5 with trunk vs > >>>fallthrough with 4.8) - it's faster only if the loop never runs. This > >>>happens irrespective of the memory clobber inline assembler statement. > > > >With -Os you've asked for smaller code, not faster code. > > > >All of the block reordering is based on heuristics -- there is no polynomial > >time and space algorithm to do it optimally, let alone the linear time and > >space we need in GCC -- so there always will be cases we do not handle > >optimally. -Os does not get as much attention as -O2 etc., as well. > > > >OTOH this seems to be a pretty common case that we could handle. Please > >open a PR to keep track of this? > I superficially looked at this a little while ago and concluded that it's > something we ought to be able to handle. However, it wasn't critical enough > to me to get familiar enough with the bbro code to deeply analyze -- thus I > put it into my gcc-8 queue. The heuristics should handle such simple case just fine. I guess some bug crept in during the years. > > > > > >>I belive that doing BB reorder in CFG layout mode is fundamentally > >>flawed but I guess it's wired up so that out-of-CFG layout honors > >>EDGE_FALLTHRU. > > > >Why is this fundamentally flawed? The reordering is much easier this way. > Agreed (that we ought to be doing reordering in CFG layout mode). In fact cfglayout was invented to implement bb-reorder originally :) Honza > > Jeff
gcc-6-20170105 is now available
Snapshot gcc-6-20170105 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170105/ 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/branches/gcc-6-branch revision 244115 You'll find: gcc-6-20170105.tar.bz2 Complete GCC MD5=75b0c4c0ca7784e7eedc0221de5023ed SHA1=b243eb3c16a2949ec0ef3a44713c0e59404b0970 Diffs from 6-20161229 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.
Re: Worse code after bbro?
Segher Boessenkool writes: > On Wed, Jan 04, 2017 at 10:05:49AM +0100, Richard Biener wrote: >> > The code size is identical, but the trunk version executes one more >> > instruction everytime the loop runs (explicit jump to .L5 with trunk vs >> > fallthrough with 4.8) - it's faster only if the loop never runs. This >> > happens irrespective of the memory clobber inline assembler statement. > > With -Os you've asked for smaller code, not faster code. > > All of the block reordering is based on heuristics -- there is no polynomial > time and space algorithm to do it optimally, let alone the linear time and > space we need in GCC -- so there always will be cases we do not handle > optimally. -Os does not get as much attention as -O2 etc., as well. > > OTOH this seems to be a pretty common case that we could handle. Please > open a PR to keep track of this? > Filed PR 79012 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79012) Regards Senthil
