https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #51 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Alexander Klepikov from comment #50)
>
> 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, it
> 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
> guess not).
>
I don't think there is a direct way to hide patterns from the combine pass,
although I could be wrong, since I haven't been tracking the combine pass
development closely for a while.
Perhaps you can look at how the left-shifts are done as a reference.
> Now concerning GCC testsuite. I ran it in such way:
>
> make check RUNTESTFLAGS="CFLAGS='$CFLAGS -I/usr/local/sh-elf/include/'
> --target_board=sh-sim\{-m2e,-m4\}\{-ml,-mb\}"
>
> There are lots of failed tests on non-patched GCC. Even if I narrow tests
> list to sh.exp, it still fails a lot of times. At last there's nothing in
> logs that produce ICE in RTL. I'm not sure I could find a crash due to the
> patch at all, even if it were there.
To test it, you first use a known good version of GCC without your patch, build
the whole toolchain from scratch and run it. Then collect the test results.
Then apply your patch, and repeat the process. Collect the test results again.
Then compare both test results. If there are any new changes in the test
results your patch is hitting something.
Usually I'd run the testsuite as follows:
make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
(running make with multiple jobs here is useful, and still it will take some
hours)
