Hi Martin,
>
> I see various ICE after your commit r236356:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71170
Sorry for the breakage. Looking into it.
Thanks,
Kugan
On Wed, May 18, 2016 at 10:38 AM, Kugan Vivekanandarajah
wrote:
Please move the whole thing under the else { } case of the ops.length
== 0, ops.length == 1 test chain
as you did for the actual emit of the negate.
>>>
>>> I see your point. However, when we remove the (-1) from t
On 05/18/2016 10:38 AM, Kugan Vivekanandarajah wrote:
> Is this Still OK. Bootstrap and regression testing on ARM, AARCH64 and
> x86-64 didn’t have any new regressions.
>
> Thanks,
> Kugan
Hello.
I see various ICE after your commit r236356:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71170
Mar
>>> Please move the whole thing under the else { } case of the ops.length
>>> == 0, ops.length == 1 test chain
>>> as you did for the actual emit of the negate.
>>>
>>
>> I see your point. However, when we remove the (-1) from the ops list, that
>> intern can result in ops.length becoming 1. Theref
On Thu, May 5, 2016 at 2:41 AM, kugan wrote:
> Hi Richard,
>
>>
>> + int last = ops.length () - 1;
>> + bool negate_result = false;
>>
>> Do
>>
>>oe &last = ops.last ();
>>
>
> Done.
>
>>
>> + if (rhs_code == MULT_EXPR
>> + && ops.length () >
Hi Richard,
+ int last = ops.length () - 1;
+ bool negate_result = false;
Do
oe &last = ops.last ();
Done.
+ if (rhs_code == MULT_EXPR
+ && ops.length () > 1
+ && ((TREE_CODE (ops[last]->op) == INTEGER_CST
and last.
On Sat, Apr 23, 2016 at 3:10 PM, kugan
wrote:
>
>>> I am not sure I understand this. I tried doing this. If I add -1 and
>>> rhs1
>>> for the NEGATE_EXPR to ops list, when it come to rewrite_expr_tree
>>> constant
>>> will be sorted early and would make it hard to generate:
>>> x + (-y * z * z
I am not sure I understand this. I tried doing this. If I add -1 and rhs1
for the NEGATE_EXPR to ops list, when it come to rewrite_expr_tree constant
will be sorted early and would make it hard to generate:
x + (-y * z * z) => x - y * z * z
Do you want to swap the constant in MULT_EXPR chai
On Thu, Apr 21, 2016 at 1:12 PM, kugan
wrote:
> Hi Richard,
>
>
> On 19/04/16 22:11, Richard Biener wrote:
>>
>> On Tue, Apr 19, 2016 at 1:36 PM, Richard Biener
>> wrote:
>>>
>>> On Tue, Apr 19, 2016 at 1:35 PM, Richard Biener
>>> wrote:
On Mon, Feb 29, 2016 at 11:53 AM, kugan
wr
Hi Richard,
On 19/04/16 22:11, Richard Biener wrote:
On Tue, Apr 19, 2016 at 1:36 PM, Richard Biener
wrote:
On Tue, Apr 19, 2016 at 1:35 PM, Richard Biener
wrote:
On Mon, Feb 29, 2016 at 11:53 AM, kugan
wrote:
Err. I think the way you implement that in reassoc is ad-hoc and not
related t
On Tue, Apr 19, 2016 at 1:36 PM, Richard Biener
wrote:
> On Tue, Apr 19, 2016 at 1:35 PM, Richard Biener
> wrote:
>> On Mon, Feb 29, 2016 at 11:53 AM, kugan
>> wrote:
Err. I think the way you implement that in reassoc is ad-hoc and not
related to reassoc at all.
In fact
On Tue, Apr 19, 2016 at 1:35 PM, Richard Biener
wrote:
> On Mon, Feb 29, 2016 at 11:53 AM, kugan
> wrote:
>>>
>>> Err. I think the way you implement that in reassoc is ad-hoc and not
>>> related to reassoc at all.
>>>
>>> In fact what reassoc is missing is to handle
>>>
>>> -y * z * (-w) * x -
On Mon, Feb 29, 2016 at 11:53 AM, kugan
wrote:
>>
>> Err. I think the way you implement that in reassoc is ad-hoc and not
>> related to reassoc at all.
>>
>> In fact what reassoc is missing is to handle
>>
>> -y * z * (-w) * x -> y * x * w * x
>>
>> thus optimize negates as if they were additio
Err. I think the way you implement that in reassoc is ad-hoc and not
related to reassoc at all.
In fact what reassoc is missing is to handle
-y * z * (-w) * x -> y * x * w * x
thus optimize negates as if they were additional * -1 entries in a
multiplication chain. And
then optimize a singl
On Fri, Feb 26, 2016 at 4:02 AM, kugan
wrote:
>
>
> Hi,
>
> This is an attempt to fix missed optimization: x + (-y * z * z) => x - y * z
> * z as reported in PR40921.
>
> Regression tested and bootstrapped on x86-64-linux-gnu with no new
> regressions.
>
> Is this OK for next stage1?
Err. I thin
Hi,
This is an attempt to fix missed optimization: x + (-y * z * z) => x - y
* z * z as reported in PR40921.
Regression tested and bootstrapped on x86-64-linux-gnu with no new
regressions.
Is this OK for next stage1?
Thanks,
Kugan
gcc/ChangeLog:
2016-02-26 Kugan Vivekanandarajah
16 matches
Mail list logo
