Christophe Lyon wrote:
> This causes my builds (all arm and aarch64 targets) to fail:
Richard Biener already committed a fix in r254498 (thanks).
It seems constants in match.pd now need wi::to_wide.
Wilco
Hi Wilco
On 7 November 2017 at 13:28, Wilco Dijkstra wrote:
> Sudi Das wrote:
>
>> Thanks, I have made the changes to the patch.
>> Also can someone please apply it for me. I do not have commit access.
>>
>> 2017-10-10 Sudakshina Das
>>
>>PR middle-end/80131
>>* match.pd: Simpl
Sudi Das wrote:
> Thanks, I have made the changes to the patch.
> Also can someone please apply it for me. I do not have commit access.
>
> 2017-10-10 Sudakshina Das
>
> PR middle-end/80131
> * match.pd: Simplify 1 << (C - x) where C = precision (x) - 1.
>
> 2017-10-10 Sudakshina
a
Sent: Monday, October 9, 2017 2:02 PM
To: Richard Biener; Sudi Das
Cc: Jakub Jelinek; GCC Patches; nd; Richard Earnshaw; James Greenhalgh
Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
Richard Biener wrote:
> I think the patch is ok with these changes but obviously we
Richard Biener wrote:
> I think the patch is ok with these changes but obviously we should try
> to address
> the code-generation issue on x86 at RTL expansion time. They are sort-of
> existing missing optimizations.
Note the only x64 specific issue is the backend expansion of 64-bit immediates
co Dijkstra; Jakub Jelinek; GCC Patches; nd; Richard Earnshaw; James
> Greenhalgh
> Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
>
> On Tue, Aug 1, 2017 at 11:14 AM, Sudi Das wrote:
>>
>>
>>
>>
>> Sorry about the delayed response but look
; Richard Earnshaw; James Greenhalgh
Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
Jakub Jelinek wrote:
> Well, we don't want to regress performance wise on one of the most important
> primary targets. I don't care that much if the RTL/backend work is done
>
Jakub Jelinek wrote:
> Well, we don't want to regress performance wise on one of the most important
> primary targets. I don't care that much if the RTL/backend work is done
> together with the patch, or as a follow-up during stage1/3, but it should be
> done, the testcases I've posted can be use
On Tue, Sep 26, 2017 at 12:44:10PM +, Sudi Das wrote:
>
> Still waiting on Jakub's comment on whether there are more things needed
> at the backend. But I have updated the patch according to Richard's
> comments.
Well, we don't want to regress performance wise on one of the most important
pr
atches; nd; Richard Earnshaw; James
Greenhalgh
Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
On Tue, Aug 1, 2017 at 11:14 AM, Sudi Das wrote:
>
>
>
>
> Sorry about the delayed response but looking at the above discussion, should
> I conclude that this is a
ret
> .sizef4, .-f4
>
>
> Thanks
>
> Sudi
>
>
>
>
> From: Wilco Dijkstra
> Sent: Thursday, April 13, 2017 1:01 PM
> To: Richard Biener; Jakub Jelinek
> Cc: Sudi Das; GCC Patches; nd; Richard Earnshaw; James Greenhalgh
> Subject: Re: [PATCH][GCC]
, w0
add sp, sp, 16
ret
.size f4, .-f4
Thanks
Sudi
From: Wilco Dijkstra
Sent: Thursday, April 13, 2017 1:01 PM
To: Richard Biener; Jakub Jelinek
Cc: Sudi Das; GCC Patches; nd; Richard Earnshaw; James Greenhalgh
Subject: Re: [PATCH][GCC] Simplification of 1U << (
Richard Biener wrote:
> It is IMHO a valid GIMPLE optimization / canonicalization.
>
> movabsq $-9223372036854775808, %rax
>
> so this should then have been generated as 1<<63?
>
> At some point variable shifts were quite expensive as well..
Yes I don't see a major difference between movabs
On Thu, Apr 13, 2017 at 01:49:01PM +0200, Richard Biener wrote:
> It is IMHO a valid GIMPLE optimization / canonicalization.
As I said, we can do it as GIMPLE canonicalization, but
we should have code to undo it if beneficial at RTL level.
And the patch has not included that.
>
> movabsq
On Thu, Apr 13, 2017 at 1:41 PM, Jakub Jelinek wrote:
> On Thu, Apr 13, 2017 at 11:33:12AM +, Wilco Dijkstra wrote:
>> Jakub Jelinek wrote:
>>
>> > No. Some constants sometimes even 7 instructions (e.g. sparc64; not
>> > talking
>> > in particular about 1ULL << 63 constant), or have one inst
On Thu, Apr 13, 2017 at 11:33:12AM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
>
> > No. Some constants sometimes even 7 instructions (e.g. sparc64; not talking
> > in particular about 1ULL << 63 constant), or have one instruction
> > that is more expensive than normal small constant
Jakub Jelinek wrote:
> No. Some constants sometimes even 7 instructions (e.g. sparc64; not talking
> in particular about 1ULL << 63 constant), or have one instruction
> that is more expensive than normal small constant load. Compare say x86_64
> movl/movq vs. movabsq, I think the latter has
On Thu, Apr 13, 2017 at 11:16:08AM +, Wilco Dijkstra wrote:
> >On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > > Hi all
> > >
> > > This is a fix for PR 80131
> > > Currently the code A << (B - C) is not simplified.
> >> However at least a more specific case of 1U << (C -x) wher
>On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > Hi all
> >
> > This is a fix for PR 80131
> > Currently the code A << (B - C) is not simplified.
>> However at least a more specific case of 1U << (C -x) where C =
>> precision(type) - 1 can be simplified to (1 << C) >> x.
>
> Is tha
On Wed, Apr 12, 2017 at 08:59:34PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 12, 2017 at 01:15:56PM -0500, Segher Boessenkool wrote:
> > On Wed, Apr 12, 2017 at 07:06:38PM +0200, Jakub Jelinek wrote:
> > > On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > > > This is a fix for PR 80131
On Wed, Apr 12, 2017 at 01:15:56PM -0500, Segher Boessenkool wrote:
> Hi,
>
> On Wed, Apr 12, 2017 at 07:06:38PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > > This is a fix for PR 80131
> > > Currently the code A << (B - C) is not simplified.
> >
Hi,
On Wed, Apr 12, 2017 at 07:06:38PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> > This is a fix for PR 80131
> > Currently the code A << (B - C) is not simplified.
> > However at least a more specific case of 1U << (C -x) where C =
> > precision(t
On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote:
> Hi all
>
> This is a fix for PR 80131
> Currently the code A << (B - C) is not simplified.
> However at least a more specific case of 1U << (C -x) where C =
> precision(type) - 1 can be simplified to (1 << C) >> x.
Is that always a win
Hi all
This is a fix for PR 80131
Currently the code A << (B - C) is not simplified.
However at least a more specific case of 1U << (C -x) where C = precision(type)
- 1 can be simplified to (1 << C) >> x.
This is done by adding a new simplification rule in match.pd
So for a test case :
unsign
24 matches
Mail list logo
