On Fri, 8 Nov 2024 at 15:30, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > > On 14/10/2024 16:28, Christophe Lyon wrote: > > > > > > On 10/14/24 16:40, Torbjorn SVENSSON wrote: > >> Hi Christophe, > >> > >> On 2024-10-14 14:16, Christophe Lyon wrote: > >>> Hi Torbjörn, > >>> > >>> > >>> On 10/13/24 19:37, Torbjörn SVENSSON wrote: > >>>> Ok for trunk? > >>>> > >>>> -- > >>>> > >>>> With the changes in r15-1579-g792f97b44ff, the constants have been > >>>> updated. This patch aligns the constants in the test cases with the > >>>> updated implementation. > >>>> > >>> > >>> Could you share a bit more details? In particular, IIUC, since the > >>> constants used now are different, why do you introduce new > >>> alternatives, rather than replace the old expected constants? > >>> > >>> Do we now generate both old & new versions, depending on some flags? > >> > >> The constants depends on if some optimization step is included or not. > >> I don't understand how this works, but the changeset that Richard > >> merged in the above commit id does cause this need. > >> I think the constants switch with -O2, but I don't know exactly what > >> part that enables it. > >> > >> From my point of view, the mov instruction could always us the higher > >> value and then do a lower amount of shifts, but don't know if that's > >> easy to achieve or not. > >> > > Indeed, these tests are exercised with several optimization levels from > > -O0 to -O3 and -Os, and late-combine is only enabled at -O2 and above, > > including -Os. So I guess the previous value is still used at -O0 and -O1. > > > > Thanks for the clarification. > > > > LGTM. > > > > Christophe > > > >> Kind regards, > >> Torbjörn > >> > >>> > >>> FTR, this is also tracked by > >>> https://linaro.atlassian.net/browse/GNU-1269 > >>> > >>> > >>> Thanks, > >>> > >>> Christophe > >>> > >>>> gcc/testsuite/ChangeLog: > >>>> > >>>> * gcc.target/arm/pure-code/no-literal-pool-m0.c: Update expected > >>>> asm. > >>>> > >>>> Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com> > >>>> --- > >>>> .../arm/pure-code/no-literal-pool-m0.c | 29 > >>>> ++++++++++++++----- > >>>> 1 file changed, 21 insertions(+), 8 deletions(-) > >>>> > >>>> diff --git a/gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool- > >>>> m0.c b/gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool-m0.c > >>>> index bd6f4af183b..effaf8b60b6 100644 > >>>> --- a/gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool-m0.c > >>>> +++ b/gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool-m0.c > >>>> @@ -95,8 +95,13 @@ test_65536 () > >>>> /* > >>>> ** test_0x123456: > >>>> ** ... > >>>> +** ( > >>>> ** movs r[0-3], #18 > >>>> ** lsls r[0-3], r[0-3], #8 > >>>> +** | > >>>> +** movs r[0-3], #144 > >>>> +** lsls r[0-3], r[0-3], #5 > >>>> +** ) > >>>> ** adds r[0-3], r[0-3], #52 > >>>> ** lsls r[0-3], r[0-3], #8 > >>>> ** adds r[0-3], r[0-3], #86 > >>>> @@ -125,18 +130,16 @@ test_0x1123456 () > >>>> return 0x1123456; > >>>> } > >>>> -/* With -Os, we generate: > >>>> - movs r0, #16 > >>>> - lsls r0, r0, r0 > >>>> - With the other optimization levels, we generate: > >>>> - movs r0, #16 > >>>> - lsls r0, r0, #16 > >>>> - hence the two alternatives. */ > >>>> /* > >>>> ** test_0x1000010: > >>>> ** ... > >>>> +** ( > >>>> ** movs r[0-3], #16 > >>>> -** lsls r[0-3], r[0-3], (#16|r[0-3]) > >>>> +** lsls r[0-3], r[0-3], #16 > >>>> +** | > >>>> +** movs r[0-3], #128 > >>>> +** lsls r[0-3], r[0-3], #13 > >>>> +** ) > >>>> ** adds r[0-3], r[0-3], #1 > >>>> ** lsls r[0-3], r[0-3], #4 > >>>> ** ... > >>>> @@ -150,8 +153,13 @@ test_0x1000010 () > >>>> /* > >>>> ** test_0x1000011: > >>>> ** ... > >>>> +** ( > >>>> ** movs r[0-3], #1 > >>>> ** lsls r[0-3], r[0-3], #24 > >>>> +** | > >>>> +** movs r[0-3], #128 > >>>> +** lsls r[0-3], r[0-3], #17 > >>>> +** ) > >>>> ** adds r[0-3], r[0-3], #17 > >>>> ** ... > >>>> */ > >>>> @@ -164,8 +172,13 @@ test_0x1000011 () > >>>> /* > >>>> ** test_m8192: > >>>> ** ... > >>>> +** ( > >>>> ** movs r[0-3], #1 > >>>> ** lsls r[0-3], r[0-3], #13 > >>>> +** | > >>>> +** movs r[0-3], #128 > >>>> +** lsls r[0-3], r[0-3], #6 > >>>> +** ) > >>>> ** rsbs r[0-3], r[0-3], #0 > >>>> ** ... > >>>> */ > >> > > Do we really need to care about the precise assembler output at all the > different optimization levels? Isn't it enough to simply check that we > don't get a literal pool entry? Eg to scan for > ldr r[0-7], .Lnnnn > > *not* being in the generated code. >
Good point. That would be less fragile indeed. I guess at the time I added that test, I wanted to check we generate the expected code sequence, where other tests checked other conditions, so that we had full coverage of -mpure-code code paths wrt to such constants Christophe > R.
