On Sun, Nov 2, 2014 at 11:34 AM, Marc Glisse wrote:
> On Fri, 31 Oct 2014, Richard Biener wrote:
>
>> On Sat, Oct 25, 2014 at 6:29 PM, Marc Glisse wrote:
>>>
>>> On Fri, 24 Oct 2014, Jeff Law wrote:
>>>
I'm starting to agree -- a later message indicated you wanted to drop
the
unlin
On Fri, 31 Oct 2014, Richard Biener wrote:
On Sat, Oct 25, 2014 at 6:29 PM, Marc Glisse wrote:
On Fri, 24 Oct 2014, Jeff Law wrote:
I'm starting to agree -- a later message indicated you wanted to drop the
unlink_stmt_vdef call and you wanted to avoid gsi_replace, that seems fine.
I'll appro
On 10/25/14 10:29, Marc Glisse wrote:
On Fri, 24 Oct 2014, Jeff Law wrote:
I'm starting to agree -- a later message indicated you wanted to drop
the unlink_stmt_vdef call and you wanted to avoid gsi_replace, that
seems fine. I'll approve once those things are taken care of.
The following pass
On 10/25/14 01:48, Marc Glisse wrote:
Without the liveness patch, their lifetime should mean that they don't
coalesce with anything. But I would expect they get their own partition
then (I am forgetting these details way too fast...). With the liveness
patch which gives them an empty lifetime, t
On Sat, Oct 25, 2014 at 6:29 PM, Marc Glisse wrote:
> On Fri, 24 Oct 2014, Jeff Law wrote:
>
>> I'm starting to agree -- a later message indicated you wanted to drop the
>> unlink_stmt_vdef call and you wanted to avoid gsi_replace, that seems fine.
>> I'll approve once those things are taken care
On Fri, 24 Oct 2014, Jeff Law wrote:
I'm starting to agree -- a later message indicated you wanted to drop the
unlink_stmt_vdef call and you wanted to avoid gsi_replace, that seems fine.
I'll approve once those things are taken care of.
The following passed bootstrap+testsuite. I wasn't sure
(replying to both messages)
On Fri, 24 Oct 2014, Jeff Law wrote:
[ https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01830.html ]
So I'm still trying to get comfortable with this patch. I guess my concerns
about having one of the undefined value SSA_NAMEs appearing in two
conflicting coalesce lis
On 10/17/14 14:41, Marc Glisse wrote:
On Thu, 16 Oct 2014, Jeff Law wrote:
BTW, I dislike having multiple DCE implementations...
Similarly. The proposal above was just to determine if we should
schedule DCE or not.
Thinking about it some more, I don't think we should need any kind of
DCE he
On 10/18/14 15:59, Marc Glisse wrote:
On Thu, 10 Jul 2014, Richard Biener wrote:
On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse
wrote:
we currently drop clobbers on variables whose address is not taken
anymore.
However, rewrite_stmt has code to replace them with an SSA_NAME with a
default def
On Thu, 10 Jul 2014, Richard Biener wrote:
On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse wrote:
we currently drop clobbers on variables whose address is not taken anymore.
However, rewrite_stmt has code to replace them with an SSA_NAME with a
default definition (an uninitialized variable), an
On Thu, 16 Oct 2014, Jeff Law wrote:
BTW, I dislike having multiple DCE implementations...
Similarly. The proposal above was just to determine if we should schedule
DCE or not.
Thinking about it some more, I don't think we should need any kind of DCE
here. The rewriting in update_ssa alread
On 10/16/14 11:52, Richard Biener wrote:
I'd walk the SSA_NAMEs at the end checking for zero uses. I'm
curious how often that will trigger :-)
Most often for the initial into SSA I guess. After that only for the
cases we rename a variable which does not happen often. SRA and
update-address-ta
On October 16, 2014 7:26:48 PM CEST, Jeff Law wrote:
>On 10/16/14 08:11, Marc Glisse wrote:
>
>>
>> I am looking into that, it must be doable. It seems not too hard, in
>> maybe_register_def, to push all results from make_ssa_name to some
>> data-structure (I don't think new_ssa_names gives me tha
On 10/16/14 08:11, Marc Glisse wrote:
I am looking into that, it must be doable. It seems not too hard, in
maybe_register_def, to push all results from make_ssa_name to some
data-structure (I don't think new_ssa_names gives me that list, but
there may be other ways to get it without introducing
On 10/16/14 05:20, Richard Biener wrote:
It doesn't even know that it has no uses (the variable still needs to be
written into SSA form). OTOH it is a missed DSE opportunity before
update-address-taken?
Perhaps it's a missed DSE prior to update-address-taken, but I suspect
there aren't many of
On Thu, Oct 16, 2014 at 4:11 PM, Marc Glisse wrote:
> On Thu, 16 Oct 2014, Richard Biener wrote:
>
>> On Wed, Oct 15, 2014 at 6:08 PM, Jeff Law wrote:
>>>
>>> On 10/15/14 08:35, Marc Glisse wrote:
>
>
>
> Would that extra pass be acceptable?
>>
>>
>> Ugh, rather not. We have too
On Thu, 16 Oct 2014, Richard Biener wrote:
On Wed, Oct 15, 2014 at 6:08 PM, Jeff Law wrote:
On 10/15/14 08:35, Marc Glisse wrote:
Would that extra pass be acceptable?
Ugh, rather not. We have too many passes ;)
I expected you would say that...
Otherwise, what do you think should be r
On Wed, Oct 15, 2014 at 6:08 PM, Jeff Law wrote:
> On 10/15/14 08:35, Marc Glisse wrote:
>>>
>>>
>>> Would that extra pass be acceptable?
Ugh, rather not. We have too many passes ;)
>>> Otherwise, what do you think should be responsible for cleaning up the
>>> dead assignments?
>>
>>
>> Does an
On 10/15/14 08:35, Marc Glisse wrote:
Would that extra pass be acceptable?
Otherwise, what do you think should be responsible for cleaning up the
dead assignments?
Does anyone have an opinion on which side needs to be improved? As a
reminder:
- we have a va_list with its address taken by va_
On Sun, 7 Sep 2014, Marc Glisse wrote:
On Sun, 27 Jul 2014, Marc Glisse wrote:
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FRO
On Sun, 27 Jul 2014, Marc Glisse wrote:
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def)
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
/* If DEF
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
/* If DEF
On Sat, Jul 12, 2014 at 8:15 AM, Marc Glisse wrote:
> On Thu, 10 Jul 2014, Richard Biener wrote:
>
>>> --- gcc/tree-into-ssa.c (revision 212109)
>>> +++ gcc/tree-into-ssa.c (working copy)
>>> @@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
>>> {
>>>tree def = DEF_FROM_PTR (de
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
/* If DEF
On 07/11/14 06:05, Michael Matz wrote:
Hi,
On Thu, 10 Jul 2014, Jeff Law wrote:
The insight to note is, that undefined SSA names should really be
coalesced with something (otherwise you lost an optimization opportunity),
but it doesn't matter with _what_ each use of the undefined name is
coale
Hi,
On Thu, 10 Jul 2014, Jeff Law wrote:
> > The insight to note is, that undefined SSA names should really be
> > coalesced with something (otherwise you lost an optimization opportunity),
> > but it doesn't matter with _what_ each use of the undefined name is
> > coalesced, you can even identif
On Fri, Jul 11, 2014 at 10:10 AM, Richard Biener
wrote:
> On Thu, Jul 10, 2014 at 8:22 PM, Jeff Law wrote:
>> On 07/10/14 09:48, Michael Matz wrote:
>>>
>>> Hi,
>>>
>>> On Thu, 10 Jul 2014, Richard Biener wrote:
>>>
Apart from the out-of-SSA patch you proposed elsewhere a possibility
is
On Thu, Jul 10, 2014 at 8:22 PM, Jeff Law wrote:
> On 07/10/14 09:48, Michael Matz wrote:
>>
>> Hi,
>>
>> On Thu, 10 Jul 2014, Richard Biener wrote:
>>
>>> Apart from the out-of-SSA patch you proposed elsewhere a possibility
>>> is to simply never mark undefined SSA names as
>>> SSA_NAME_OCCURS_IN
On 07/10/14 09:48, Michael Matz wrote:
Hi,
On Thu, 10 Jul 2014, Richard Biener wrote:
Apart from the out-of-SSA patch you proposed elsewhere a possibility
is to simply never mark undefined SSA names as
SSA_NAME_OCCURS_IN_ABNORMAL_PHI ... (or not mark those
as must-coalesce).
The insight to n
Hi,
On Thu, 10 Jul 2014, Richard Biener wrote:
> Apart from the out-of-SSA patch you proposed elsewhere a possibility
> is to simply never mark undefined SSA names as
> SSA_NAME_OCCURS_IN_ABNORMAL_PHI ... (or not mark those
> as must-coalesce).
The insight to note is, that undefined SSA names sh
On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse wrote:
> Hello,
>
> we currently drop clobbers on variables whose address is not taken anymore.
> However, rewrite_stmt has code to replace them with an SSA_NAME with a
> default definition (an uninitialized variable), and I believe
> rewrite_update_st
On Mon, 7 Jul 2014, Jeff Law wrote:
On 07/06/14 08:23, Marc Glisse wrote:
What is the lifetime of an SSA_NAME with a default definition? The way
we handle it now, we start from the uses and go back to all blocks that
can reach one of the uses, since there is no defining statement where we
could
On 07/06/14 08:23, Marc Glisse wrote:
What is the lifetime of an SSA_NAME with a default definition? The way
we handle it now, we start from the uses and go back to all blocks that
can reach one of the uses, since there is no defining statement where we
could stop
Right, that's exactly what I wou
On Sun, Jul 6, 2014 at 4:23 PM, Marc Glisse wrote:
> On Mon, 30 Jun 2014, Jeff Law wrote:
>
>> On 06/28/14 16:33, Marc Glisse wrote:
>>>
>>> In an earlier version of the patch, I was using
>>> get_or_create_ssa_default_def (cfun, sym);
>>> (I was reusing the same variable). This passed bootstrap+t
On Sun, 6 Jul 2014, pins...@gmail.com wrote:
The below patch won't work for parameters.
Er, that's why I am testing: TREE_CODE (var) == VAR_DECL
(and the patch passed the testsuite with all languages)
Could you be more specific about what won't work?
--
Marc Glisse
> On Jul 6, 2014, at 7:23 AM, Marc Glisse wrote:
>
>> On Mon, 30 Jun 2014, Jeff Law wrote:
>>
>>> On 06/28/14 16:33, Marc Glisse wrote:
>>> In an earlier version of the patch, I was using
>>> get_or_create_ssa_default_def (cfun, sym);
>>> (I was reusing the same variable). This passed bootstra
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/28/14 16:33, Marc Glisse wrote:
In an earlier version of the patch, I was using
get_or_create_ssa_default_def (cfun, sym);
(I was reusing the same variable). This passed bootstrap+testsuite on
all languages except for ada. Indeed, the compiler wanted t
On 06/28/14 16:33, Marc Glisse wrote:
In an earlier version of the patch, I was using
get_or_create_ssa_default_def (cfun, sym);
(I was reusing the same variable). This passed bootstrap+testsuite on
all languages except for ada. Indeed, the compiler wanted to coalesce
several SSA_NAMEs, including
Hello,
we currently drop clobbers on variables whose address is not taken
anymore. However, rewrite_stmt has code to replace them with an SSA_NAME
with a default definition (an uninitialized variable), and I believe
rewrite_update_stmt should do the same. This allows us to warn sometimes
(see
40 matches
Mail list logo
