From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 66F903858401; Thu, 1 Jun 2023 11:18:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 66F903858401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685618285; bh=LV+4rC3gwwaFWc6hHc/S7Hcta5i3vZiJ+SShpzkSfEs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=su2lR0QH7W08wxxETAoBtX0PG2FAbNMUzEKULi+KQSF7QcqlSmhCB3AE5SmjUMqG0 4OYoxcPbCUeWRgTQG5rTDaX+Y0+4qlSHVvXJQ5h3clrMYGvsZPp94/ezdxD4cEoyVs pV+iSrAFCRPRfuEUMQ4YjRozY1wEeqKw34XbuAys= From: "klepikov.alex+bugs at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/54089] [SH] Refactor shift patterns Date: Thu, 01 Jun 2023 11:18:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: klepikov.alex+bugs at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: olegendo at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D54089 --- Comment #50 from Alexander Klepikov --- > > I've found that my patch catches integer division. In short, it appears= to > > work unpredictable. It looks like there's no easy way to catch right sh= ift. >=20 > What do you mean it catches integer division? There could be several plac= es > during compilation, where the compiler will try to convert integer divisi= on > to right shifts. But it will not do so unless it's wrong. The patterns = you > have added shouldn't match a division operation. Ooh, my bad! You are absolutely right. A function is inlined and division is converted to 4 'shar's which at combine pass are catched by 'define_insn "ashrsi3_libcall_collapsed"' which is little unexpected to me. Of course, i= t is expanded at 'split' pass to lib call. 5 and less right shifts should not convert to a lib call, but that can be easily corrected. But maybe there is a way to exclude particular insn from combine pass? (I g= uess not). Here are the files that confused me: $ cat pr49880-3.c /* Check that the option -mdiv=3Dcall-table works. */ /* { dg-do link } */ /* { dg-options "-mdiv=3Dcall-table" } */ int test00 (int a, int b) { return a / b; } unsigned int test01 (unsigned int a, unsigned b) { return a / b; } int main (int argc, char** argv) { return test00 (argc, 123) + test01 (argc, 123); } Not-patched GCC $ cat pr49880-3.s.clean .file "pr49880-3.c" .text .text .align 1 .align 2 .global _test00 .type _test00, @function _test00: mov.l .L4,r0 sts.l pr,@-r15 jsr @r0 nop lds.l @r15+,pr rts nop .L5: .align 2 .L4: .long ___sdivsi3 .size _test00, .-_test00 .align 1 .align 2 .global _test01 .type _test01, @function _test01: mov.l .L8,r0 sts.l pr,@-r15 jsr @r0 nop lds.l @r15+,pr rts nop .L9: .align 2 .L8: .long ___udivsi3 .size _test01, .-_test01 .section .text.startup,"ax",@progbits .align 1 .align 2 .global _main .type _main, @function _main: mov.l .L11,r1 dmuls.l r1,r4 sts mach,r0 shar r0 shar r0 shar r0 shar r0 mov r4,r1 shll r1 subc r1,r1 sub r1,r0 mov.l .L12,r1 dmulu.l r1,r4 sts mach,r1 sub r1,r4 shlr r4 add r4,r1 shlr2 r1 shlr2 r1 shlr2 r1 rts add r1,r0 .L13: .align 2 .L11: .long 558694933 .L12: .long 174592167 .size _main, .-_main .ident "GCC: (GNU) 13.1.0" Patched GCC $ cat pr49880-3.s .file "pr49880-3.c" .text .text .align 1 .align 2 .global _test00 .type _test00, @function _test00: mov.l .L4,r0 sts.l pr,@-r15 jsr @r0 nop lds.l @r15+,pr rts nop .L5: .align 2 .L4: .long ___sdivsi3 .size _test00, .-_test00 .align 1 .align 2 .global _test01 .type _test01, @function _test01: mov.l .L8,r0 sts.l pr,@-r15 jsr @r0 nop lds.l @r15+,pr rts nop .L9: .align 2 .L8: .long ___udivsi3 .size _test01, .-_test01 .section .text.startup,"ax",@progbits .align 1 .align 2 .global _main .type _main, @function _main: mov.l .L12,r2 mov r4,r1 sts.l pr,@-r15 dmuls.l r2,r4 mov.l .L13,r2 jsr @r2 sts mach,r4 mov r1,r2 shll r2 subc r2,r2 mov r4,r0 sub r2,r0 mov.l .L14,r2 dmulu.l r2,r1 sts mach,r2 sub r2,r1 shlr r1 add r1,r2 shlr2 r2 shlr2 r2 shlr2 r2 add r2,r0 lds.l @r15+,pr rts nop .L15: .align 2 .L12: .long 558694933 .L13: .long ___ashiftrt_r4_4 .L14: .long 174592167 .size _main, .-_main .ident "GCC: (GNU) 13.1.0" Now concerning GCC testsuite. I ran it in such way: make check RUNTESTFLAGS=3D"CFLAGS=3D'$CFLAGS -I/usr/local/sh-elf/include/' --target_board=3Dsh-sim\{-m2e,-m4\}\{-ml,-mb\}" There are lots of failed tests on non-patched GCC. Even if I narrow tests l= ist to sh.exp, it still fails a lot of times. At last there's nothing in logs t= hat produce ICE in RTL. I'm not sure I could find a crash due to the patch at a= ll, even if it were there. And finally, 'parallel' appears to be unnecessary, thank you for pointing.=