public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
       [not found] <bug-36770-4@http.gcc.gnu.org/bugzilla/>
@ 2013-12-24 23:13 ` steven at gcc dot gnu.org
  0 siblings, 0 replies; 4+ messages in thread
From: steven at gcc dot gnu.org @ 2013-12-24 23:13 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu.org

--- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Gunnar von Boehn from comment #2)
> Correct would be:
> test2:
>         lwz 0,0(3)
>         stwu 0,4(3)
>         blr
> 
> Is you can see the created bad code is just the same.
> This is independent of the register pinning.

At least with gcc 4.7.1 and gcc 4.9.0 (r206195) the register pinning
makes all the difference.

$ cat t.c
register int * src asm("r15");

int test1( ){
    src[1]=src[0];
    src++;
}

int *test2(int *a ){
    a[1]=a[0];
    a++;
    return a;
}

$ ./cc1 -quiet -O2 t.c
$ cat t.s
...
.L.test1:
        lwz 10,0(15)
        mr 9,15
        addi 15,15,4
        stw 10,4(9)
        blr
...
.L.test2:
        lwz 9,0(3)
        stwu 9,4(3)
        blr


This is basically the same as bug 44281.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
  2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
  2008-07-11 11:56 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity bonzini at gnu dot org
  2008-07-18 13:42 ` bonzini at gnu dot org
@ 2008-07-18 14:14 ` bonzini at gnu dot org
  2 siblings, 0 replies; 4+ messages in thread
From: bonzini at gnu dot org @ 2008-07-18 14:14 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from bonzini at gnu dot org  2008-07-18 14:13 -------
Hmm, even that wouldn't restore the optimization.  The problem here is that
there is another access via b, like

   a <- b + c
   *b
   *(b + c)

The bad placement of the first assignment (bad because doing it the other way
round would have lower register pressure) in turn happens as soon as
gimplification.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
  2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
  2008-07-11 11:56 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity bonzini at gnu dot org
@ 2008-07-18 13:42 ` bonzini at gnu dot org
  2008-07-18 14:14 ` bonzini at gnu dot org
  2 siblings, 0 replies; 4+ messages in thread
From: bonzini at gnu dot org @ 2008-07-18 13:42 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from bonzini at gnu dot org  2008-07-18 13:41 -------
auto-inc-dec should be taught about transforming

   a <- b + c
   ...
   *(b + c)

into

   a <- b
   ...
   *(a += c) pre


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug middle-end/36770] PowerPC missed autoincrement opportunity
  2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
@ 2008-07-11 11:56 ` bonzini at gnu dot org
  2008-07-18 13:42 ` bonzini at gnu dot org
  2008-07-18 14:14 ` bonzini at gnu dot org
  2 siblings, 0 replies; 4+ messages in thread
From: bonzini at gnu dot org @ 2008-07-11 11:56 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from bonzini at gnu dot org  2008-07-11 11:56 -------
Yes, the code produced shows that something (probably fwprop, I trust Andrew
though I'd like to see dumps) is turning the GIMPLE code

  temp = a[0];
  a[1] = temp;
  temp++;

into something harder to optimize.  It might be also a pass-ordering problem.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
            Summary|PowerPC generated PTR code  |PowerPC missed autoincrement
                   |inefficiency                |opportunity


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-12-24 23:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-36770-4@http.gcc.gnu.org/bugzilla/>
2013-12-24 23:13 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity steven at gcc dot gnu.org
2008-07-09 14:57 [Bug c/36770] New: PowerPC generated PTR code ineffiency gunnar at greyhound-data dot com
2008-07-11 11:56 ` [Bug middle-end/36770] PowerPC missed autoincrement opportunity bonzini at gnu dot org
2008-07-18 13:42 ` bonzini at gnu dot org
2008-07-18 14:14 ` bonzini at gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).