Hi Bernd,
On 08/01/16 13:22, Bernd Schmidt wrote:
On 01/08/2016 02:11 PM, Kyrill Tkachov wrote:
How's this?
Hmm. Almost there, but...
- if (then_bb && else_bb && !a_simple && !b_simple
- && (!bbs_ok_for_cmove_arith (then_bb, else_bb)
- || !bbs_ok_for_cmove_arith (else_bb,
Ok, this works too. Here is a version that adds orig_x to the if_info
struct and passes it down
to bbs_ok_for_cmove_arith.
This passes bootstrap and test on arm, aarch64, x86_64.
I think this is ok.
Bernd
On 07/01/16 14:00, Kyrill Tkachov wrote:
On 07/01/16 13:47, Bernd Schmidt wrote:
On 01/07/2016 02:45 PM, Kyrill Tkachov wrote:
On 07/01/16 11:52, Bernd Schmidt wrote:
I looked and this is indeed the case. Still slightly scary. Should the
MEM be rtx_equal_p to TO_RENAME? It would be good to
On 01/08/2016 02:11 PM, Kyrill Tkachov wrote:
How's this?
Hmm. Almost there, but...
- if (then_bb && else_bb && !a_simple && !b_simple
- && (!bbs_ok_for_cmove_arith (then_bb, else_bb)
- || !bbs_ok_for_cmove_arith (else_bb, then_bb)))
+ rtx orig_x = x;
+ if (then_bb &&
Hi Bernd,
On 06/01/16 10:36, Kyrill Tkachov wrote:
Hi Bernd,
On 05/01/16 18:19, Kyrill Tkachov wrote:
On 05/01/16 17:06, Kyrill Tkachov wrote:
On 05/01/16 16:34, Bernd Schmidt wrote:
On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:
This works around the issue but we don't want to do
On 01/07/2016 02:45 PM, Kyrill Tkachov wrote:
On 07/01/16 11:52, Bernd Schmidt wrote:
I looked and this is indeed the case. Still slightly scary. Should the
MEM be rtx_equal_p to TO_RENAME? It would be good to test or at least
assert this.
I tried asserting that and it caused trouble
On 07/01/16 13:47, Bernd Schmidt wrote:
On 01/07/2016 02:45 PM, Kyrill Tkachov wrote:
On 07/01/16 11:52, Bernd Schmidt wrote:
I looked and this is indeed the case. Still slightly scary. Should the
MEM be rtx_equal_p to TO_RENAME? It would be good to test or at least
assert this.
I tried
Hi Bernd,
On 05/01/16 18:19, Kyrill Tkachov wrote:
On 05/01/16 17:06, Kyrill Tkachov wrote:
On 05/01/16 16:34, Bernd Schmidt wrote:
On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:
This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because
On 05/01/16 16:34, Bernd Schmidt wrote:
On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:
This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things like:
x = cond ? x + 1 : x - 1
i.e. source of
On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:
This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things like:
x = cond ? x + 1 : x - 1
i.e. source of the set in both blocks reads and writes
On 12/21/2015 10:23 AM, Kyrill Tkachov wrote:
Here is a version integrating the new checks into bbs_ok_for_cmove_arith.
We might as well do it there since it already iterates over all the
instructions in the basic blocks.
The patch looks somewhat complicated and asymmetrical to me. I tried to
On 05/01/16 13:42, Bernd Schmidt wrote:
On 12/21/2015 10:23 AM, Kyrill Tkachov wrote:
Here is a version integrating the new checks into bbs_ok_for_cmove_arith.
We might as well do it there since it already iterates over all the
instructions in the basic blocks.
The patch looks somewhat
On 05/01/16 17:06, Kyrill Tkachov wrote:
On 05/01/16 16:34, Bernd Schmidt wrote:
On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:
This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things
Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01966.html
Thanks,
Kyrill
On 21/12/15 09:23, Kyrill Tkachov wrote:
On 18/12/15 13:16, Bernd Schmidt wrote:
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the
On 18/12/15 13:16, Bernd Schmidt wrote:
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter
Hi all,
In this PR we have a THEN and an ELSE block where one uses the condition reg
from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter first and dead code elimination later sees this and
eliminates the first
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter first and dead code elimination later sees
On 18/12/15 13:16, Bernd Schmidt wrote:
On 12/18/2015 02:07 PM, Kyrill Tkachov wrote:
In this PR we have a THEN and an ELSE block where one uses the condition
reg from the preceeding comparison
but the other block has an arithmetic operation that clobbers the CC reg.
ifcvt emits the latter
18 matches
Mail list logo
