-Original Message-
From: Kai Tietz [mailto:ktiet...@googlemail.com]
Sent: Thursday, October 27, 2011 5:36 PM
To: Jiangning Liu
Cc: Michael Matz; Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org;
Richard Henderson
Subject: Re: [patch tree-optimization]: Improve handling of
-Original Message-
From: Michael Matz [mailto:m...@suse.de]
Sent: Wednesday, October 26, 2011 11:47 PM
To: Kai Tietz
Cc: Jiangning Liu; Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org;
Richard Henderson
Subject: Re: [patch tree-optimization]: Improve handling of
2011/10/27 Jiangning Liu jiangning@arm.com:
-Original Message-
From: Michael Matz [mailto:m...@suse.de]
Sent: Wednesday, October 26, 2011 11:47 PM
To: Kai Tietz
Cc: Jiangning Liu; Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org;
Richard Henderson
Subject: Re: [patch
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Michael Matz
Sent: Tuesday, October 11, 2011 10:45 PM
To: Kai Tietz
Cc: Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org; Richard
Henderson
Subject: Re: [patch
2011/10/26 Jiangning Liu jiangning@arm.com:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Michael Matz
Sent: Tuesday, October 11, 2011 10:45 PM
To: Kai Tietz
Cc: Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org;
Hi,
On Wed, 26 Oct 2011, Jiangning Liu wrote:
-
- if (LOGICAL_OP_NON_SHORT_CIRCUIT)
- {
- if (code != orig_code || lhs != orig_lhs || rhs !=
orig_rhs)
- return build2_loc (loc, code, truth_type, lhs, rhs);
- return NULL_TREE;
- }
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
Yes, this part introduced different behavior for this small case,
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
Well, as far as I understand C specification and sequence
2011/10/26 Michael Matz m...@suse.de:
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
Yes, this part introduced different behavior for this small case,
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
Well, as far as I
I describe the sample more closely here
extern int global = 0;
extern int *a = NULL;
void catchSigSegV( int sig )
{
a = global;
}
int foo (int j)
{
signal (SIGSEGV, catchSigSegV);
if (*a global) return 2;
return 0;
}
I admit that in most cases such a scenario is not common. This sample
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
the case can be produced quite easily.
extern int global = 0;
if (*a global) ...
See? You had to
2011/10/26 Michael Matz m...@suse.de:
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
int f(char *i, int j)
{
if (*i j!=2)
return *i;
else
return j;
}
the case can be produced quite easily.
extern int global = 0;
if
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
well, if such a function is used as inline and we know for it that j has
value != 2, then we have here a big difference. For your first example,
we still have to do the memory access to *i, even if we are not
interested in result.
Actually we
2011/10/26 Michael Matz m...@suse.de:
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
well, if such a function is used as inline and we know for it that j has
value != 2, then we have here a big difference. For your first example,
we still have to do the memory access to *i, even if we are not
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
So you would mean that memory dereferencing shouldn't be considered as
side-effect at all?
No. I haven't said this at all. Of course it's a side-effect, but we're
allowed to remove existing ones (under some circumstances). We're not
allowed to
On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
So I committed the gimplify patch separate. And here is the remaining
fold-const patch.
The important tests here are in gcc.dg/tree-ssa/builtin-expect[1-4].c, which
cover the one special-case for branching.
2011/10/17 Richard Guenther richard.guent...@gmail.com:
On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
So I committed the gimplify patch separate. And here is the remaining
fold-const patch.
The important tests here are in
On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/17 Richard Guenther richard.guent...@gmail.com:
On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
So I committed the gimplify patch separate. And here is the remaining
2011/10/17 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/17 Richard Guenther richard.guent...@gmail.com:
On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
So I committed the
On Mon, Oct 17, 2011 at 1:31 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/17 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/17 Richard Guenther richard.guent...@gmail.com:
On Fri, Oct 14, 2011 at 9:43 PM,
Ok, I see. This might be profitable to do that. So fold_truth_op
hunk looks like this
@@ -5149,13 +5176,6 @@ fold_truthop (location_t loc, enum tree_
build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
ll_arg, rl_arg),
On Mon, Oct 17, 2011 at 2:22 PM, Kai Tietz ktiet...@googlemail.com wrote:
Ok, I see. This might be profitable to do that. So fold_truth_op
hunk looks like this
@@ -5149,13 +5176,6 @@ fold_truthop (location_t loc, enum tree_
build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
Sure,
Is simplier and also handles (A T[-IF] (B T-IF C) - (A T B) T-IF C
case, which can happen by framing in conditions.
@@ -8380,13 +8400,65 @@ fold_truth_andor (location_t loc, enum t
lhs is another similar operation, try to merge its rhs with our
rhs. Then try to merge our lhs
On Mon, Oct 17, 2011 at 3:36 PM, Kai Tietz ktiet...@googlemail.com wrote:
Sure,
Is simplier and also handles (A T[-IF] (B T-IF C) - (A T B) T-IF C
case, which can happen by framing in conditions.
@@ -8380,13 +8400,65 @@ fold_truth_andor (location_t loc, enum t
lhs is another similar
On Thu, Oct 13, 2011 at 3:25 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this new version addresses the comments from you.
On gimplify.c's gimplify_expr we didn't handled the case that operands
for TRUTH-AND/OR/XOR expressions need to have same operand-size in
case of transformation
Hello,
this new version addresses the comments from Michael and additional fixes
an latent issue shown up by this rewrite in fold-const.
On gimplify.c's gimple_boolify we didn't handled the case that operands
for TRUTH-expressions need to have same operand-size for transformation to
bitwise
On Thu, Oct 13, 2011 at 1:25 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this new version addresses the comments from Michael and additional fixes
an latent issue shown up by this rewrite in fold-const.
On gimplify.c's gimple_boolify we didn't handled the case that operands
for
2011/10/13 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 13, 2011 at 1:25 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this new version addresses the comments from Michael and additional fixes
an latent issue shown up by this rewrite in fold-const.
On gimplify.c's
Hello,
this new version addresses the comments from you.
On gimplify.c's gimplify_expr we didn't handled the case that operands
for TRUTH-AND/OR/XOR expressions need to have same operand-size in
case of transformation to bitwise-binary operation. This shows up
for Fortran, as there are more
Hi,
On Thu, 13 Oct 2011, Kai Tietz wrote:
this new version addresses the comments from Michael and additional fixes
an latent issue shown up by this rewrite in fold-const.
On gimplify.c's gimple_boolify we didn't handled the case that operands
for TRUTH-expressions need to have same
Hi,
On Wed, 12 Oct 2011, Kai Tietz wrote:
And I think it could use some overview of the transformation done like in
the initial patch, ala:
Transform ((A B) C) into (A (B C)).
and
Or (A B) into (A B). for this part:
+ /* Needed for sequence points to handle
2011/10/12 Michael Matz m...@suse.de:
Hi,
On Wed, 12 Oct 2011, Kai Tietz wrote:
And I think it could use some overview of the transformation done like in
the initial patch, ala:
Transform ((A B) C) into (A (B C)).
and
Or (A B) into (A B). for this part:
+ /*
Hi,
On Wed, 12 Oct 2011, Kai Tietz wrote:
Hmm? What do you mean? Both operations are binary. ANDIF is '', AND
is ''. In fold-const.c comments we usually use the C notations of the
operations.
See TRUTH_AND_EXPR is in C-notation and TRUTH_ANDIF_EXPR is also
.
Ah right, confusing
Hi,
On Mon, 10 Oct 2011, Kai Tietz wrote:
To ensure that we use simple_operand_p in all cases, beside for
branching AND/OR chains, in same way as before, I added to this function
an additional argument, by which the looking into comparisons can be
activated.
Better make it a separate
So updated version for patch. It creates new simple_operand_p_2
function instead of modifying simple_operand_p function.
ChangeLog
2011-10-11 Kai Tietz kti...@redhat.com
* fold-const.c (simple_operand_p_2): New function.
(fold_truthop): Rename to
(fold_truth_andor_1):
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
Better make it a separate function the first tests your new
conditions, and then calls simple_operand_p.
Well, either I make it a new function and call it instead of
simple_operand_p,
That's what I meant, yes.
@@ -5149,13 +5176,6 @@
2011/10/11 Michael Matz m...@suse.de:
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
Better make it a separate function the first tests your new
conditions, and then calls simple_operand_p.
Well, either I make it a new function and call it instead of
simple_operand_p,
That's what I meant,
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
So updated version for patch. It creates new simple_operand_p_2
function instead of modifying simple_operand_p function.
FWIW: I also can't think of a nice short name for that predicate function
:) One thing: move the test for TREE_SIDE_EFFECTS to
2011/10/7 Kai Tietz ktiet...@googlemail.com:
Hello,
this is the updated version with the suggestion
2011/10/7 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz kti...@redhat.com wrote:
+ ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
+
On Mon, Oct 10, 2011 at 12:35 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/7 Kai Tietz ktiet...@googlemail.com:
Hello,
this is the updated version with the suggestion
2011/10/7 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz kti...@redhat.com
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 12:35 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/7 Kai Tietz ktiet...@googlemail.com:
Hello,
this is the updated version with the suggestion
2011/10/7 Richard Guenther richard.guent...@gmail.com:
On
Sample had a typo. Correct sample has of course to return r.
int foo ()
{
int c, r = 0;
if ((c = foo ()) != 0 c 20)
r = 1;
return r;
}
On Mon, Oct 10, 2011 at 12:47 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 12:35 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/7 Kai Tietz ktiet...@googlemail.com:
Hello,
this is the updated version with
On Fri, Oct 7, 2011 at 11:36 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this is the updated version with the suggestion
2011/10/7 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz kti...@redhat.com wrote:
+ ((TREE_CODE_CLASS (TREE_CODE
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Fri, Oct 7, 2011 at 11:36 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello,
this is the updated version with the suggestion
2011/10/7 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz
On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz ktiet...@googlemail.com wrote:
Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
has to be checked that the LHS code is same as outer CODE, as
otherwise we wouldn't apply different TRUTH-IF only on inner RHS of
LHS, which is of
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz ktiet...@googlemail.com wrote:
Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
has to be checked that the LHS code is same as outer CODE, as
otherwise we wouldn't apply
On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz ktiet...@googlemail.com wrote:
Recent patch had a thinko on rhs of inner lhs check for TRUTH-IF. It
has to be checked
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 2:29 PM, Kai Tietz ktiet...@googlemail.com wrote:
Recent patch had a thinko on rhs
Hi,
On Mon, 10 Oct 2011, Kai Tietz wrote:
extern int foo (void); /* foo modifies gbl1 */
int gbl1 = 0;
int foo (int ns1)
{
if (ns1 foo () gbl1)
return 1;
return 0;
}
so chain of trees has to look like this:
(ANDIF (ns1 (ANDIF foo () gbl1))
Okay, indeed. I was wrong when
On Mon, Oct 10, 2011 at 5:07 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 4:06 PM, Kai Tietz ktiet...@googlemail.com wrote:
2011/10/10 Richard Guenther richard.guent...@gmail.com:
On Mon, Oct 10, 2011 at 2:29 PM,
On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz kti...@redhat.com wrote:
Hi,
I modified the patch so, that it always just converts two leafs of a
TRUTH(AND|OR)IF chain into a TRUTH_(AND|OR) expression, if branch costs are
high and leafs are simple without side-effects.
Additionally I added some
Hello,
this is the updated version with the suggestion
2011/10/7 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 4:25 PM, Kai Tietz kti...@redhat.com wrote:
+ ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
+ TREE_CODE (arg1) != TRUTH_NOT_EXPR
+
Hello,
Sorry attached non-updated change. Here with proper attached patch.
This patch improves in fold_truth_andor the generation of branch-conditions for
targets having LOGICAL_OP_NON_SHORT_CIRCUIT set. If right-hand side operation
of a TRUTH_(OR|AND)IF_EXPR is simple operand, has no
On Thu, Oct 6, 2011 at 11:28 AM, Kai Tietz kti...@redhat.com wrote:
Hello,
Sorry attached non-updated change. Here with proper attached patch.
This patch improves in fold_truth_andor the generation of branch-conditions
for targets having LOGICAL_OP_NON_SHORT_CIRCUIT set. If right-hand side
2011/10/6 Richard Guenther richard.guent...@gmail.com:
On Thu, Oct 6, 2011 at 11:28 AM, Kai Tietz kti...@redhat.com wrote:
Hello,
Sorry attached non-updated change. Here with proper attached patch.
This patch improves in fold_truth_andor the generation of branch-conditions
for targets
Hi,
On Thu, 6 Oct 2011, Richard Guenther wrote:
+ ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
+ TREE_CODE (arg1) != TRUTH_NOT_EXPR)
+ || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0)
? simple_operand_p would have rejected both ! and
On Thu, Oct 6, 2011 at 3:49 PM, Michael Matz m...@suse.de wrote:
Hi,
On Thu, 6 Oct 2011, Richard Guenther wrote:
+ ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
+ TREE_CODE (arg1) != TRUTH_NOT_EXPR)
+ || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1,
Hi,
I modified the patch so, that it always just converts two leafs of a
TRUTH(AND|OR)IF chain into a TRUTH_(AND|OR) expression, if branch costs are
high and leafs are simple without side-effects.
Additionally I added some testcases for it.
2011-10-06 Kai Tietz kti...@redhat.com
*
2011/10/6 Michael Matz m...@suse.de:
Hi,
On Thu, 6 Oct 2011, Richard Guenther wrote:
+ ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison
+ TREE_CODE (arg1) != TRUTH_NOT_EXPR)
+ || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0)
? simple_operand_p
Hi,
On Thu, 6 Oct 2011, Kai Tietz wrote:
That's not the hole story. The difference between TRUTH_(AND|OR)IF_EXPR
and TRUTH_(AND|OR)_EXPR are, that for TRUTH_(AND|OR)IF_EXPR gimplifier
creates a COND expression, but for TRUTH_(AND|OR)_EXPR it doesn't.
Yes, of course. That is what
2011/10/6 Michael Matz m...@suse.de:
Hi,
On Thu, 6 Oct 2011, Kai Tietz wrote:
That's not the hole story. The difference between TRUTH_(AND|OR)IF_EXPR
and TRUTH_(AND|OR)_EXPR are, that for TRUTH_(AND|OR)IF_EXPR gimplifier
creates a COND expression, but for TRUTH_(AND|OR)_EXPR it doesn't.
On Thu, Oct 06, 2011 at 05:28:36PM +0200, Kai Tietz wrote:
None. I had this implemented first. But Richard was concerned about
making non-IF conditions too long.I understand that point that it
might not that good to always modify unconditionally to AND/OR chain.
For example
if (a1 a2
Hi,
On Thu, 6 Oct 2011, Kai Tietz wrote:
at which point this association doesn't make sense anymore, as
Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and
therefore it isn't transformed into and AND.
Right ...
((W AND X) AND Y) AND Z
is just as fine. So, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/06/11 09:37, Jakub Jelinek wrote:
On Thu, Oct 06, 2011 at 05:28:36PM +0200, Kai Tietz wrote:
None. I had this implemented first. But Richard was concerned
about making non-IF conditions too long.I understand that
point that it might
2011/10/6 Michael Matz m...@suse.de:
Hi,
On Thu, 6 Oct 2011, Kai Tietz wrote:
at which point this association doesn't make sense anymore, as
Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and
therefore it isn't transformed into and AND.
Right ...
((W AND X) AND Y)
65 matches
Mail list logo
