On Mon, Feb 25, 2013 at 12:39 PM, Yuri Rumyantsev wrote:
> Hi Richard,
>
> Please, prepare the patch as you proposed.
> I checked that it helps Coremrak 1.0.
The attached works for me (works for the testcase, that is, tree forwprop
performs the requested optimization).
Richard.
> Best regards.
Hi Richard,
Please, prepare the patch as you proposed.
I checked that it helps Coremrak 1.0.
Best regards.
Yuri.
2013/2/25 Richard Biener :
> On Thu, Feb 21, 2013 at 4:42 PM, Yuri Rumyantsev wrote:
>> Richard,
>>
>> This does not fit to my fix since if we have another pattern like
>> t = (
On Thu, Feb 21, 2013 at 4:42 PM, Yuri Rumyantsev wrote:
> Richard,
>
> This does not fit to my fix since if we have another pattern like
> t = (u8)((x & 1) ^ ((u8)y & 1));
> where y has short type, for rhs operand type sinkning (or hoisting as
> you prefer) still will be performed but I don't
Richard,
This does not fit to my fix since if we have another pattern like
t = (u8)((x & 1) ^ ((u8)y & 1));
where y has short type, for rhs operand type sinkning (or hoisting as
you prefer) still will be performed but I don't see any reason for
converting (u8)y & 1 --> (u8)(y & 1) if y has u
On Thu, Feb 21, 2013 at 4:16 PM, Yuri Rumyantsev wrote:
> Richard,
>
> Sorry for my previous message - I did not undersatnd it properly.
>
> Anyway I proposed another fix that avoid (type) x & c --> (type) (x &
> (type-x) c) transformation if x has short type:
>
> +++ gcc/tree-ssa-forwprop.c
Richard,
Sorry for my previous message - I did not undersatnd it properly.
Anyway I proposed another fix that avoid (type) x & c --> (type) (x &
(type-x) c) transformation if x has short type:
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -1789,8 +1789,11 @@
defcodefor_name (arg1, &def1_
On Thu, Feb 21, 2013 at 3:26 PM, Yuri Rumyantsev wrote:
> Richard,
>
> I double checked that with and without my fix compiler produces the
> same output with -fdump-tree-optimized.
For what testcase?
Richard.
> What patch did you apply? I think that you should apply the second one
> - 56175.dif
Richard,
I double checked that with and without my fix compiler produces the
same output with -fdump-tree-optimized.
What patch did you apply? I think that you should apply the second one
- 56175.diff.
Yuri.
2013/2/21 Richard Biener :
> On Thu, Feb 21, 2013 at 2:41 PM, Yuri Rumyantsev wrote:
>
On Thu, Feb 21, 2013 at 2:41 PM, Yuri Rumyantsev wrote:
> Richard,
>
> This regression was introduced by Kai
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01988.html
>
> 2011-06-27 Kai Tietz
>
> * tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
> type sinking.
>
Richard,
This regression was introduced by Kai
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01988.html
2011-06-27 Kai Tietz
* tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
type sinking.
* tree-ssa-math-opts.c (execute_optimize_bswap): Separate
search
On Thu, Feb 21, 2013 at 1:39 PM, Yuri Rumyantsev wrote:
> Richard,
>
> As we know Kai is working on this problem for 4.9 and I assume that
> type sinking will be deleted from forwprop pass. Could we stay on this
> fix but more common fix will be done.
Well, unless you show it is a regression the
Richard,
As we know Kai is working on this problem for 4.9 and I assume that
type sinking will be deleted from forwprop pass. Could we stay on this
fix but more common fix will be done.
I also can propose to introduce new hook for it but need to know your
opinion since we don't went to waste our t
On Wed, Feb 20, 2013 at 4:41 PM, Yuri Rumyantsev wrote:
> Richard,
>
> First of all, your proposal to move type sinking to the end of
> function does not work since we handle each statement in function and
> we want that 1st type folding of X & C will not happen.
> Note that we have the following
Richard,
First of all, your proposal to move type sinking to the end of
function does not work since we handle each statement in function and
we want that 1st type folding of X & C will not happen.
Note that we have the following sequence of gimple before forwprop1:
x.0_10 = (signed char) x_8;
On Wed, Feb 20, 2013 at 1:00 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> This patch is aimed to recognize (A & C) ^ (B & C) -> (A ^ B) & C
> pattern in simpify_bitwise_binary for short integer types.
> The fix is very simple - we simply turn off short type sinking at the
> first pass of forward propa
Hi All,
This patch is aimed to recognize (A & C) ^ (B & C) -> (A ^ B) & C
pattern in simpify_bitwise_binary for short integer types.
The fix is very simple - we simply turn off short type sinking at the
first pass of forward propagation allows to get
+10% speedup for important benchmark Coremark 1
16 matches
Mail list logo
