[Bug optimization/8781] Pessimization of functional-style code

[Bug optimization/8781] Pessimization of functional-style code

[pinskia@physics.uc.edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia@physics.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |enhancement

[Bug optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2003-08-03 17:52:55         |2003-11-05 07:25:04
               date|                            |
   Target Milestone|---                         |tree-ssa


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-05 07:25 -------
The problem is that GCC does puts objects on the stack too soon, maybe be able to fix 
this on the tree-ssa branch.

[Bug optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-01 04:01 -------
SRA did not help this either.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2003-11-05 07:25:04         |2003-12-01 04:01:24
               date|                            |


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

[Bug optimization/8781] Pessimization of functional-style code

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2003-12-01 04:20 -------
This seems more related to references and aliasing than anything else.

Try changing const predicate &pred to const predicate pred, and you'll get:

.globl _Z1xv
        .type   _Z1xv, @function
_Z1xv:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        call    _Z1fv
        leave
        ret
        .size   _Z1xv, .-_Z1xv


-- 


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

[Bug optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-20 16:54 -------
The problem for the tree-ssa is being discused here: <http://gcc.gnu.org/ml/gcc/2004-01/
msg01419.html>.

-- 


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

[Bug optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-03 05:14 -------
I think this is caused by the C++ Front-end, I will look to see my patch to stop lowering 
fixes this bug (I think it does).

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


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

[Bug optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-03 05:46 -------
Actually it is not caused by the front-end but it is almost fixed on the tree-ssa now:
  pred<D1940> = f;
  pred<D1947>.pred = &pred<D1940>;
  pred<D1954>.pred = &pred<D1947>;
  pred<D1961>.pred = &pred<D1954>;
  pred<D1968>.pred = &pred<D1961>;
  pred<D1975>.pred = &pred<D1968>;
  pred<D1982>.pred = &pred<D1975>;
  pred<D1989>.pred = &pred<D1982>;
  pred<D1996>.pred = &pred<D1989>;
  <D2053> = f ();

Now all we have to do is remove the stores and this would be fixed.

-- 


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

[Bug optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-08 07:37 -------
Looks like I was using a different sources for this because it is not fixed at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2003-12-17 01:40:02         |2004-03-08 07:37:49
               date|                            |


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

[Bug tree-optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-23 23:30 -------
Mine, the problem now is there is an extra cast which is wrong, I have a patch to fix this but I need to 
convence everyone is correct as the types are the same really.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug tree-optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|rtl-optimization            |tree-optimization
   Target Milestone|3.5.0                       |---


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

[Bug tree-optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-02 04:45 -------
Much newer and simpler patch: <http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00087.html> for 
at least the cast problem.  But that just gets back to the problem in comment #7.  Which I refer to the 
lowering problem.

-- 


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

[Bug tree-optimization/8781] Pessimization of functional-style code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-23 05:24 -------
Not mine anymore, it is an aliasing issue:
  #   V_MUST_DEF <pred<D2020>_54>;
  pred<D2020> = f<D1558>;

....
  #   pred<D2024>_97 = V_MAY_DEF <pred<D2024>_72>;
  #   pred<D2028>_98 = V_MAY_DEF <pred<D2028>_69>;
  #   pred<D2032>_99 = V_MAY_DEF <pred<D2032>_66>;
  #   pred<D2036>_100 = V_MAY_DEF <pred<D2036>_63>;
  #   pred<D2040>_101 = V_MAY_DEF <pred<D2040>_60>;
  #   pred<D2044>_102 = V_MAY_DEF <pred<D2044>_57>;
  #   pred<D2048>_103 = V_MAY_DEF <pred<D2048>_49>;
  #   TMT.31<D2104>_50 = V_MAY_DEF <TMT.31<D2104>_52>;
  #   TMT.32<D2105>_46 = V_MAY_DEF <TMT.32<D2105>_48>;
  #   TMT.33<D2106>_42 = V_MAY_DEF <TMT.33<D2106>_44>;
  #   TMT.34<D2107>_38 = V_MAY_DEF <TMT.34<D2107>_40>;
  #   TMT.35<D2108>_41 = V_MAY_DEF <TMT.35<D2108>_39>;
  #   TMT.36<D2109>_47 = V_MAY_DEF <TMT.36<D2109>_45>;
  #   TMT.37<D2110>_53 = V_MAY_DEF <TMT.37<D2110>_51>;
  #   TMT.38<D2111>_59 = V_MAY_DEF <TMT.38<D2111>_58>;
  #   TMT.39<D2112>_62 = V_MAY_DEF <TMT.39<D2112>_61>;
  #   VUSE <pred<D2020>_54>;
  T.26<D2098> = f ();

I wonder if we should not figure out something about function calls again or something else is going 
wrong.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-25 01:57 -------
Diego, this is not a regression, but it would be kind to get a quick analysys 
of what is going wrong and/or spot enhancement opportunities in alias analysys. 
Can you allocate a little time to investigate?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org
            Summary|Pessimization of functional-|Pessimization of C++
                   |style code                  |(functional) code


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

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[dnovillo at gcc dot gnu dot org]

------- Additional Comments From dnovillo at gcc dot gnu dot org  2004-08-25 13:45 -------
(In reply to comment #12)
> Diego, this is not a regression, but it would be kind to get a quick analysys 
> of what is going wrong and/or spot enhancement opportunities in alias analysys. 
> Can you allocate a little time to investigate?
>
The most likely problem is that alias analysis is being tricked into thinking
that &pred escapes because it is being squirreled away into 'pred.pred = &pred'.

Since we don't keep structures in SSA form, we immediately give up on addresses
that are stored inside a structure.  Alias analysis sees the store and says 'oh,
I don't know where else that may go so I will just assume that it escapes'. 
There's a FIXME in tree-ssa-alias.c precisely because of this.

Implementing a full-fledge escape analysis framework would probably cure this. 
There may also be in-between solutions to achieve some of the lower hanging fruit.


Diego.

-- 


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

Re: [Bug tree-optimization/8781] Pessimization of C++ (functional) code

[Diego Novillo]

On Wed, 2004-08-25 at 09:45, dnovillo at gcc dot gnu dot org wrote:

> Implementing a full-fledge escape analysis framework would probably cure this. 
> There may also be in-between solutions to achieve some of the lower hanging fruit.
> 
I forgot to add.  Daniel's field-sensitive aliasing and/or the
interprocedural PTA may get this correctly.


Diego.

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[dnovillo at redhat dot com]

------- Additional Comments From dnovillo at redhat dot com  2004-08-25 13:58 -------
Subject: Re:  Pessimization of C++ (functional)
	code

On Wed, 2004-08-25 at 09:45, dnovillo at gcc dot gnu dot org wrote:

> Implementing a full-fledge escape analysis framework would probably cure this. 
> There may also be in-between solutions to achieve some of the lower hanging fruit.
> 
I forgot to add.  Daniel's field-sensitive aliasing and/or the
interprocedural PTA may get this correctly.


Diego.



-- 


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

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-24 06:28 -------
The problem here is:

  #   predD.1714_2 = V_MUST_DEF <predD.1714_1>;
  predD.1714 = fD.1555;
  #   predD.1718_36 = V_MAY_DEF <predD.1718_9>;
  predD.1718.predD.1583 = &predD.1714;
  #   predD.1714_41 = V_MAY_DEF <predD.1714_2>;
  #   predD.1718_42 = V_MAY_DEF <predD.1718_36>;  <-- Notice this, this is because we had took its
       address at one point
  #   TMT.1D.1744_45 = V_MAY_DEF <TMT.1D.1744_31>;
  #   TMT.2D.1745_25 = V_MAY_DEF <TMT.2D.1745_30>;
  #   TMT.3D.1746_27 = V_MAY_DEF <TMT.3D.1746_28>;
  #   TMT.4D.1747_33 = V_MAY_DEF <TMT.4D.1747_26>;
  D.1738_32 = f ();


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |alias
   Last reconfirmed|2004-03-08 07:37:49         |2004-11-24 06:28:26
               date|                            |


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

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-03 02:50 -------
hmm, why are things being marked as call clobered when their addresses don't escape at all.

Mostly:
D.1928_31, is dereferenced, its value escapes, points-to anything

which is the variable for the function call, that does not make sense at all.

-- 


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

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-03 03:03 -------
The real problem can be seen with:
int f(void);
int h(void);

int g(int a)
{
  int (*ff)(void) = f;
  int (**g)(void);
  g = &ff;

  (*g)();
  h();
  (*g)();
}

we mark the value which we calling as escaping:
D.1289_5, is dereferenced, its value escapes, points-to anything
D.1289_6, is dereferenced, its value escapes, points-to anything

that is wrong.

-- 


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

[Bug tree-optimization/8781] Pessimization of C++ (functional) code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-03 03:35 -------
Even though comment #17 is correct, it is not the full story (I have a fix for the issue in comment #17).  
The real problem is that we don't consider function decls as constants so consider stuff we should not 
as call clobbered as there no way the address of the function can change.

This seems like a big defect in the current tree-ssa aliasing.

-- 


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