--- Comment #17 from rguenth at gcc dot gnu dot org 2009-04-03 10:26
---
Subject: Bug 23940
Author: rguenth
Date: Fri Apr 3 10:24:28 2009
New Revision: 145494
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145494
Log:
2009-04-03 Richard Guenther rguent...@suse.de
PR
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-04-03 10:29
---
Fixed for 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-22 14:23 ---
Re. Comment #14 -- Fixed on AIB?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-22 19:05
---
Yes indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-07-15 12:38
---
Confirmed. The dead stmts hanging off unreleased (ex-VOP) SSA_NAMEs are
a major annoyance.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jimbob at google dot com 2006-12-20 21:44 ---
(In reply to comment #11)
I had it mostly working, but the changes are pretty invasive as no one ever
has
to set or clear SSA_NAME_DEF_STMT any more, its always simply right. Its
too
invasive for stage 3 thats
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-15 16:38
---
Actually this can cause compile time problems even with checking disabled
because there are some passes which loop through all SSA_NAMEs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Additional Comments From amacleod at redhat dot com 2005-09-30 14:53
---
I'm fine with the releasessaname.diff.txt
you aren't doing anything different than we normally do now. I prefer this over
adding a flag to bsi_remove for sure.
I looked into an alternative which follows up on
--- Additional Comments From amacleod at redhat dot com 2005-09-19 14:03
---
I thought there was a discussion in
http://gcc.gnu.org/ml/gcc/2005-08/msg00692.html
where the solution for dealing with releasing ssa names now that we have
immediate use data available all the time is to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:23 ---
(In reply to comment #1)
where the solution for dealing with releasing ssa names now that we have
immediate use data available all the time is to simply add a lightning fast
pass
which removes unused
--- Additional Comments From amacleod at redhat dot com 2005-09-19 15:45
---
Did you read the original thread?
We aren't going back and forth over anything.
Diego added release_defs in 08/2004 because we did not have immediate_use
information freely available at the time. The
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-19
15:49 ---
(In reply to comment #3)
Did you read the original thread?
Well then you do it since you made this mess in the first place.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
--- Additional Comments From amacleod at redhat dot com 2005-09-19 15:59
---
I don't understand. Exactly what mess did I make?
We also probably have to set SSA_NAME_DEF_STMT to NULL in bsi_remove in order to
be sure that an SSA name with no uses isn't actually associated with a stmt
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-19
16:05 ---
Subject: Re: SSA_NAMEs are not released after no longer being used.
On Sep 19, 2005, at 11:59 AM, amacleod at redhat dot com wrote:
We also probably have to set SSA_NAME_DEF_STMT to NULL in
--- Additional Comments From amacleod at redhat dot com 2005-09-19 16:33
---
Its not the same thing since we arent actually releasing an SSA_NAME until
between passes. All we are doing is clearing the SSA_NAME_DEF_STMT field.
True that inserting a stmt after bsi_remove will not set
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-19
16:44 ---
Subject: Re: SSA_NAMEs are not released after no longer being used.
On Sep 19, 2005, at 12:33 PM, amacleod at redhat dot com wrote:
And that will not work for the SSA_NAMEs used for aliasing and
--- Additional Comments From amacleod at redhat dot com 2005-09-19 18:10
---
Do you mean SSA_NAME_DEF_FOR_STMT for i_4 would NOT be NULLed since we didnt
call bsi_remove on it?
if it is NULL, then it has no uses and we can simply remove it with the trip
through the SSA_NAME table.
If
--- Additional Comments From amacleod at redhat dot com 2005-09-19 20:34
---
Actually, it occurs to me that we might be able to make the entire
SSA_NAME_DEF_STMT process completely transparent, including the setting of it.
The operand cache knows whenever an SSA_NAME is added to any
18 matches
Mail list logo
