[Bug c++/14455] New: Inner Altivec loop contains load/stores but not all registers being used

[Bug c++/14455] New: Inner Altivec loop contains load/stores but not all registers being used

[tjw at omnigroup dot com]

Often in inner loops (no child functions called, big loop count), there will be several (many!) Altivec 
registers left unused.

The attached file demonstrates the problem, when built with tree-ssa with:

%PREFIX/bin/g++ -Winline -mdynamic-no-pic -fno-exceptions -O3 -maltivec -fstrict-aliasing 
-finline-functions -finline-limit=1000000000 -falign-loops=16 --param large-function-
growth=1000000 --param inline-unit-growth=1000 iterator_10.cpp -S -o /tmp/iterator_10.s

In my real world code, this is a big problem since I'm have code that does:

    - long computation for some answer
    - compute some address to ADD to the answer to (and the address is almost never in cache)
    - load from answer address
    - start on next loop
    - add answer and old answer and store

The problem is that the compiler totally blows the approach since it immediately stores the loaded 
old answer to the stack, causing a stall waiting for the load to complete (and thus preventing any 
asynchrony with the load and the computation in the next loop).

-- 
           Summary: Inner Altivec loop contains load/stores but not all
                    registers being used
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tjw at omnigroup dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.2.0
  GCC host triplet: powerpc-apple-darwin7.2.0
GCC target triplet: powerpc-apple-darwin7.2.0


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

[Bug c++/14455] Inner Altivec loop contains load/stores but not all registers being used

[tjw at omnigroup dot com]

------- Additional Comments From tjw at omnigroup dot com  2004-03-06 04:32 -------
Created an attachment (id=5874)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5874&action=view)
Test input


-- 


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

[Bug optimization/14455] Inner Altivec loop contains load/stores but not all registers being used

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-06 04:51 -------
The problem I see is that there is no store/load motion in the loop for the C.* and state.* (note that 
they really are C->* and state->* as they are references), this is caused by aliasing anylasis not 
knowing that they can not be the same object.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |optimization
     Ever Confirmed|                            |1
           Keywords|                            |pessimizes-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-03-06 04:51:17
               date|                            |


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

[Bug optimization/14455] Structs that cannot alias are SRA'd

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Inner Altivec loop contains |Structs that cannot alias
                   |load/stores but not all     |are SRA'd
                   |registers being used        |
   Target Milestone|---                         |tree-ssa


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

[Bug optimization/14455] Structs that cannot alias are SRA'd

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-06 04:58 -------
here is a work around:
void foo(const Constants &C1, State &state1)
{
  Constants C = C1;
  State state = state1;
    for (int i = 0; i < 100; i++) {
	state.step(C);
    }
  state1 = state;
}

-- 


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

[Bug optimization/14455] Structs that cannot alias are not SRA'd

[tjw at omnigroup dot com]

------- Additional Comments From tjw at omnigroup dot com  2004-04-07 03:14 -------
This workaround doesn't entirely solve the problem, I think.  The issue is that passing 'C' here 
invokes an implicit copy constructor.  If the constructor isn't defined, memcpy is used (bad for 
inlining).  If the constructor is defined, is must be defined to take 'const Constants &C' as the 
argument and we're back in a similar boat as before.  Attaching an updated example.  This code is 
definitely better, but there should be zero load/stores in the inner loop but there still are a few.




-- 


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

[Bug tree-optimization/14455] Structs that cannot alias are not SRA'd

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.5.0                       |---


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

[Bug tree-optimization/14455] Structs that cannot alias are not SRA'd

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-20 17:26 -------
The other issue is that the altivec builtins are not marked so we think they can clobber the what the 
pointers point to.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |23983


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