* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
@ 2003-06-09 15:29 ` pinskia@physics.uc.edu
2003-11-05 7:25 ` pinskia at gcc dot gnu dot org
` (17 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia@physics.uc.edu @ 2003-06-09 15:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
2003-06-09 15:29 ` [Bug optimization/8781] Pessimization of functional-style code pinskia@physics.uc.edu
@ 2003-11-05 7:25 ` pinskia at gcc dot gnu dot org
2003-12-01 4:01 ` pinskia at gcc dot gnu dot org
` (16 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-11-05 7:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
2003-06-09 15:29 ` [Bug optimization/8781] Pessimization of functional-style code pinskia@physics.uc.edu
2003-11-05 7:25 ` pinskia at gcc dot gnu dot org
@ 2003-12-01 4:01 ` pinskia at gcc dot gnu dot org
2003-12-01 4:20 ` dberlin at gcc dot gnu dot org
` (15 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-12-01 4:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (2 preceding siblings ...)
2003-12-01 4:01 ` pinskia at gcc dot gnu dot org
@ 2003-12-01 4:20 ` dberlin at gcc dot gnu dot org
2004-01-20 16:54 ` pinskia at gcc dot gnu dot org
` (14 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: dberlin at gcc dot gnu dot org @ 2003-12-01 4:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (3 preceding siblings ...)
2003-12-01 4:20 ` dberlin at gcc dot gnu dot org
@ 2004-01-20 16:54 ` pinskia at gcc dot gnu dot org
2004-03-03 5:14 ` pinskia at gcc dot gnu dot org
` (13 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-01-20 16:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (4 preceding siblings ...)
2004-01-20 16:54 ` pinskia at gcc dot gnu dot org
@ 2004-03-03 5:14 ` pinskia at gcc dot gnu dot org
2004-03-03 5:46 ` pinskia at gcc dot gnu dot org
` (12 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-03-03 5:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (5 preceding siblings ...)
2004-03-03 5:14 ` pinskia at gcc dot gnu dot org
@ 2004-03-03 5:46 ` pinskia at gcc dot gnu dot org
2004-03-08 7:37 ` pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-03-03 5:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (6 preceding siblings ...)
2004-03-03 5:46 ` pinskia at gcc dot gnu dot org
@ 2004-03-08 7:37 ` pinskia at gcc dot gnu dot org
2004-05-24 6:46 ` [Bug tree-optimization/8781] " pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-03-08 7:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (7 preceding siblings ...)
2004-03-08 7:37 ` pinskia at gcc dot gnu dot org
@ 2004-05-24 6:46 ` pinskia at gcc dot gnu dot org
2004-05-24 11:08 ` pinskia at gcc dot gnu dot org
` (9 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-05-24 6:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (8 preceding siblings ...)
2004-05-24 6:46 ` [Bug tree-optimization/8781] " pinskia at gcc dot gnu dot org
@ 2004-05-24 11:08 ` pinskia at gcc dot gnu dot org
2004-06-02 4:45 ` pinskia at gcc dot gnu dot org
` (8 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-05-24 11:08 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Component|rtl-optimization |tree-optimization
Target Milestone|3.5.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (9 preceding siblings ...)
2004-05-24 11:08 ` pinskia at gcc dot gnu dot org
@ 2004-06-02 4:45 ` pinskia at gcc dot gnu dot org
2004-08-23 5:24 ` pinskia at gcc dot gnu dot org
` (7 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-06-02 4:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of functional-style code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (10 preceding siblings ...)
2004-06-02 4:45 ` pinskia at gcc dot gnu dot org
@ 2004-08-23 5:24 ` pinskia at gcc dot gnu dot org
2004-08-25 1:57 ` [Bug tree-optimization/8781] Pessimization of C++ (functional) code giovannibajo at libero dot it
` (6 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-08-23 5:24 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (11 preceding siblings ...)
2004-08-23 5:24 ` pinskia at gcc dot gnu dot org
@ 2004-08-25 1:57 ` giovannibajo at libero dot it
2004-08-25 13:45 ` dnovillo at gcc dot gnu dot org
` (5 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: giovannibajo at libero dot it @ 2004-08-25 1:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (12 preceding siblings ...)
2004-08-25 1:57 ` [Bug tree-optimization/8781] Pessimization of C++ (functional) code giovannibajo at libero dot it
@ 2004-08-25 13:45 ` dnovillo at gcc dot gnu dot org
2004-08-25 13:58 ` Diego Novillo
2004-08-25 13:58 ` dnovillo at redhat dot com
` (4 subsequent siblings)
18 siblings, 1 reply; 22+ messages in thread
From: dnovillo at gcc dot gnu dot org @ 2004-08-25 13:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bug tree-optimization/8781] Pessimization of C++ (functional) code
2004-08-25 13:45 ` dnovillo at gcc dot gnu dot org
@ 2004-08-25 13:58 ` Diego Novillo
0 siblings, 0 replies; 22+ messages in thread
From: Diego Novillo @ 2004-08-25 13:58 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (13 preceding siblings ...)
2004-08-25 13:45 ` dnovillo at gcc dot gnu dot org
@ 2004-08-25 13:58 ` dnovillo at redhat dot com
2004-11-24 6:28 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: dnovillo at redhat dot com @ 2004-08-25 13:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (14 preceding siblings ...)
2004-08-25 13:58 ` dnovillo at redhat dot com
@ 2004-11-24 6:28 ` pinskia at gcc dot gnu dot org
2005-08-03 2:50 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-11-24 6:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (15 preceding siblings ...)
2004-11-24 6:28 ` pinskia at gcc dot gnu dot org
@ 2005-08-03 2:50 ` pinskia at gcc dot gnu dot org
2005-08-03 3:03 ` pinskia at gcc dot gnu dot org
2005-08-03 3:35 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-08-03 2:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (16 preceding siblings ...)
2005-08-03 2:50 ` pinskia at gcc dot gnu dot org
@ 2005-08-03 3:03 ` pinskia at gcc dot gnu dot org
2005-08-03 3:35 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-08-03 3:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <20021202022601.8781.wesslen@users.sourceforge.net>
` (17 preceding siblings ...)
2005-08-03 3:03 ` pinskia at gcc dot gnu dot org
@ 2005-08-03 3:35 ` pinskia at gcc dot gnu dot org
18 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-08-03 3:35 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <bug-8781-4038@http.gcc.gnu.org/bugzilla/>
@ 2006-01-08 5:32 ` pinskia at gcc dot gnu dot org
2006-04-05 16:05 ` rguenth at gcc dot gnu dot org
1 sibling, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-01-08 5:32 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-08 05:32 -------
Hmm, maybe there is really something else going on here:
struct noop_t<int (*)()>D.1999 D.2016;
struct noop_t<int (*)()>D.1999 predD.2575;
predD.2575 = (struct noop_t<int (*)()>D.1999) D.2016;
Hmm, why is there a cast there? They are the same types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug tree-optimization/8781] Pessimization of C++ (functional) code
[not found] <bug-8781-4038@http.gcc.gnu.org/bugzilla/>
2006-01-08 5:32 ` pinskia at gcc dot gnu dot org
@ 2006-04-05 16:05 ` rguenth at gcc dot gnu dot org
1 sibling, 0 replies; 22+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2006-04-05 16:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from rguenth at gcc dot gnu dot org 2006-04-05 16:05 -------
Because they are not the same:
(gdb) call debug_generic_expr(0xb7e31c94)
struct noop_t<int (*)()>D.2008
(gdb) call debug_generic_expr(0xb7e3505c)
struct noop_t<int (*)()>D.2008
generated by
#0 build1_stat (code=NOP_EXPR, type=0xb7e3505c, node=0xb7d843c8)
at /space/rguenther/src/svn/gcc/gcc/tree.c:2779
#1 0x085440ad in fold_build1_stat (code=NOP_EXPR, type=0xb7e3505c,
op0=0xb7d843c8) at /space/rguenther/src/svn/gcc/gcc/fold-const.c:11099
#2 0x084eaf25 in fold_convert (type=0xb7e3505c, arg=0xb7d843c8)
at /space/rguenther/src/svn/gcc/gcc/fold-const.c:1996
#3 0x0828659b in setup_one_parameter (id=0xbfffeb54, p=0xb7e38000,
value=0xb7d843c8, fn=0xb7e37100, bb=0xb7e400a0, vars=0xbfffe924)
at /space/rguenther/src/svn/gcc/gcc/tree-inline.c:1069
#4 0x0828692e in initialize_inlined_parameters (id=0xbfffeb54,
args=0xb7e36468, static_chain=0x0, fn=0xb7e37100, bb=0xb7e400a0)
at /space/rguenther/src/svn/gcc/gcc/tree-inline.c:1125
#5 0x08289168 in expand_call_inline (bb=0xb7e400a0, stmt=0xb7d7f1b0,
tp=0xb7d7f1d0, data=0xbfffeb54)
(gdb) call cxx_types_compatible_p (0xb7e31c94, 0xb7e3505c)
$1 = 1
(gdb) call debug_tree(0xb7e31c94)
<record_type 0xb7e31c94 noop_t<int (*)()> needs-constructing type_1 type_5
type_6 SI
size <integer_cst 0xb7d773d8 type <integer_type 0xb7d8905c bit_size_type>
constant invariant 32>
unit size <integer_cst 0xb7d77168 type <integer_type 0xb7d89000 unsigned
int> constant invariant 4>
align 32 symtab 0 alias set -1
fields <field_decl 0xb7e31e60 pred
type <reference_type 0xb7e31ebc type <pointer_type 0xb7e31da8>
unsigned SI size <integer_cst 0xb7d773d8 32> unit size <integer_cst
0xb7d77168 4>
align 32 symtab 0 alias set -1>
readonly used private unsigned nonlocal decl_3 SI file t.C line 5 size
<integer_cst 0xb7d773d8 32> unit size <integer_cst 0xb7d77168 4>
align 32 offset_align 128
offset <integer_cst 0xb7d77180 constant invariant 0>
bit offset <integer_cst 0xb7d77948 constant invariant 0> context
<record_type 0xb7e31c94 noop_t<int (*)()>>
chain <type_decl 0xb7dfff08 noop_t type <record_type 0xb7e31c94
noop_t<int (*)()>>
external nonlocal suppress-debug decl_4 VOID file t.C line 4
align 8 context <record_type 0xb7e31c94 noop_t<int (*)()>>
>>
needs-constructor X(constX&) this=(X&) n_parents=0 use_template=1
interface-unknown
pointer_to_this <pointer_type 0xb7e31f18> chain <type_decl 0xb7dffea0
noop_t<int (*)()>>>
(gdb) call debug_tree(0xb7e3505c)
<record_type 0xb7e3505c noop_t<int (*)()> readonly needs-constructing type_1
type_5 SI
size <integer_cst 0xb7d773d8 type <integer_type 0xb7d8905c bit_size_type>
constant invariant 32>
unit size <integer_cst 0xb7d77168 type <integer_type 0xb7d89000 unsigned
int> constant invariant 4>
align 32 symtab 0 alias set -1
fields <field_decl 0xb7e31e60 pred
type <reference_type 0xb7e31ebc type <pointer_type 0xb7e31da8>
unsigned SI size <integer_cst 0xb7d773d8 32> unit size <integer_cst
0xb7d77168 4>
align 32 symtab 0 alias set -1>
readonly used private unsigned nonlocal decl_3 SI file t.C line 5 size
<integer_cst 0xb7d773d8 32> unit size <integer_cst 0xb7d77168 4>
align 32 offset_align 128
offset <integer_cst 0xb7d77180 constant invariant 0>
bit offset <integer_cst 0xb7d77948 constant invariant 0> context
<record_type 0xb7e31c94 noop_t<int (*)()>>
chain <type_decl 0xb7dfff08 noop_t type <record_type 0xb7e31c94
noop_t<int (*)()>>
external nonlocal suppress-debug decl_4 VOID file t.C line 4
align 8 context <record_type 0xb7e31c94 noop_t<int (*)()>>
>>
needs-constructor X(constX&) this=(X&) n_parents=0 use_template=1
interface-unknown
pointer_to_this <pointer_type 0xb7e350b8> reference_to_this <reference_type
0xb7e353f4>>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8781
^ permalink raw reply [flat|nested] 22+ messages in thread