Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-17 Thread Richard Biener
On Fri, 17 May 2024, Manolis Tsamis wrote: > On Fri, May 17, 2024 at 12:22 PM Richard Biener wrote: > > > > On Fri, 17 May 2024, Manolis Tsamis wrote: > > > > > Hi Richard, > > > > > > While I was re-testing the latest version of this patch I noticed that > > > it FAILs an AArch64 test,

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-17 Thread Manolis Tsamis
On Fri, May 17, 2024 at 12:22 PM Richard Biener wrote: > > On Fri, 17 May 2024, Manolis Tsamis wrote: > > > Hi Richard, > > > > While I was re-testing the latest version of this patch I noticed that > > it FAILs an AArch64 test, gcc.target/aarch64/subsp.c. With the patch > > we generate one

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-17 Thread Richard Biener
On Fri, 17 May 2024, Manolis Tsamis wrote: > Hi Richard, > > While I was re-testing the latest version of this patch I noticed that > it FAILs an AArch64 test, gcc.target/aarch64/subsp.c. With the patch > we generate one instruction more: > > sbfiz x1, x1, 4, 32 > stp x29,

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-17 Thread Manolis Tsamis
Hi Richard, While I was re-testing the latest version of this patch I noticed that it FAILs an AArch64 test, gcc.target/aarch64/subsp.c. With the patch we generate one instruction more: sbfiz x1, x1, 4, 32 stp x29, x30, [sp, -16]! add x1, x1, 16 mov

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-16 Thread Richard Biener
On Tue, May 14, 2024 at 10:58 AM Manolis Tsamis wrote: > > New patch with the requested changes can be found below. > > I don't know how much this affects SCEV, but I do believe that we > should incorporate this change somehow. I've seen various cases of > suboptimal address calculation codegen

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-14 Thread Manolis Tsamis
New patch with the requested changes can be found below. I don't know how much this affects SCEV, but I do believe that we should incorporate this change somehow. I've seen various cases of suboptimal address calculation codegen that boil down to this. gcc/match.pd | 31

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-02 Thread Richard Biener
On Thu, 2 May 2024, Manolis Tsamis wrote: > On Thu, May 2, 2024 at 4:00 PM Richard Biener wrote: > > > > On Tue, 23 Apr 2024, Manolis Tsamis wrote: > > > > > The original motivation for this pattern was that the following function > > > does > > > not fold to 'return 1': > > > > > > int foo(int

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-02 Thread Manolis Tsamis
On Thu, May 2, 2024 at 4:00 PM Richard Biener wrote: > > On Tue, 23 Apr 2024, Manolis Tsamis wrote: > > > The original motivation for this pattern was that the following function > > does > > not fold to 'return 1': > > > > int foo(int *a, int j) > > { > > int k = j - 1; > > return a[j - 1]

Re: [PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-05-02 Thread Richard Biener
On Tue, 23 Apr 2024, Manolis Tsamis wrote: > The original motivation for this pattern was that the following function does > not fold to 'return 1': > > int foo(int *a, int j) > { > int k = j - 1; > return a[j - 1] == a[k]; > } > > The expression ((unsigned long) (X +- C1) * C2) appears

[PATCH] MATCH: Maybe expand (T)(A + C1) * C2 and (T)(A + C1) * C2 + C3 [PR109393]

2024-04-23 Thread Manolis Tsamis
The original motivation for this pattern was that the following function does not fold to 'return 1': int foo(int *a, int j) { int k = j - 1; return a[j - 1] == a[k]; } The expression ((unsigned long) (X +- C1) * C2) appears frequently as part of address calculations (e.g. arrays). These