Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-10-01 Thread Richard Sandiford via Gcc-patches
Alex Coplan writes: > Hi Christophe, > > On 08/09/2020 10:14, Christophe Lyon wrote: >> On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote: >> > >> > gcc/ChangeLog: >> > >> > * config/aarch64/aarch64.md >> > (*adds__): Ensure extended operand >> > agrees with width of

Re: [PING][PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-09-30 Thread Christophe Lyon via Gcc-patches
On Wed, 30 Sep 2020 at 16:03, Alex Coplan wrote: > > Ping. Are these testsuite fixes for ILP32 OK? > LGTM, by looking at the patch (I didn't run it in ilp32 mode) Thanks Christophe > On 18/09/2020 17:15, Alex Coplan wrote: > > Hi Christophe, > > > > On 08/09/2020 10:14, Christophe Lyon wrote:

[PING][PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-09-30 Thread Alex Coplan via Gcc-patches
Ping. Are these testsuite fixes for ILP32 OK? On 18/09/2020 17:15, Alex Coplan wrote: > Hi Christophe, > > On 08/09/2020 10:14, Christophe Lyon wrote: > > On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote: > > > > > > gcc/ChangeLog: > > > > > > * config/aarch64/aarch64.md > > >

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-09-18 Thread Alex Coplan
Hi Christophe, On 08/09/2020 10:14, Christophe Lyon wrote: > On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote: > > > > gcc/ChangeLog: > > > > * config/aarch64/aarch64.md > > (*adds__): Ensure extended operand > > agrees with width of extension specifier. > >

RE: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-09-08 Thread Alex Coplan
Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: 08 September 2020 09:15 > To: Alex Coplan > Cc: gcc Patches ; Richard Earnshaw > ; Marcus Shawcroft > Subject: Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend > syn

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-09-08 Thread Christophe Lyon via Gcc-patches
On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote: > > Hello, > > Given the following C function: > > double *f(double *p, unsigned x) > { > return p + x; > } > > prior to this patch, GCC at -O2 would generate: > > f: > add x0, x0, x1, uxtw 3 > ret > > but this add

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-08-21 Thread Richard Sandiford
Alex Coplan writes: > Hi Richard, > >> -Original Message- >> From: Richard Sandiford >> Sent: 18 August 2020 09:35 >> To: Alex Coplan >> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ; >> Marcus Shawcroft ; Kyrylo Tkachov >> >> Sub

RE: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-08-19 Thread Alex Coplan
Hi Richard, > -Original Message- > From: Richard Sandiford > Sent: 18 August 2020 09:35 > To: Alex Coplan > Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > > Subject: Re: [PATCH] aarch64: Don't generate invalid zero/sign-e

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-08-18 Thread Iain Sandoe via Gcc-patches
Richard Sandiford wrote: Alex Coplan writes: Note that an obvious omission here is that this patch does not touch the mult patterns such as *add__mult_. I found that I couldn't hit these patterns with C code since multiplications by powers of two always get turned into shifts by earlier RTL

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-08-18 Thread Richard Sandiford
Alex Coplan writes: > Note that an obvious omission here is that this patch does not touch the > mult patterns such as *add__mult_. I found > that I couldn't hit these patterns with C code since multiplications by > powers of two always get turned into shifts by earlier RTL passes. If > there's a

[PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

2020-08-17 Thread Alex Coplan
Hello, Given the following C function: double *f(double *p, unsigned x) { return p + x; } prior to this patch, GCC at -O2 would generate: f: add x0, x0, x1, uxtw 3 ret but this add instruction uses architecturally-invalid syntax: the width of the third operand