Hi,
( For some weird reason I keep losing Sebastien's messages ... )
On Sat, 2024-07-06 at 07:35 -0600, Jeff Law wrote:
>
> On 7/5/24 1:28 AM, Sébastien Michelland wrote:
> > Hi Oleg!
> >
> > > I don't understand why this is being limited to SH3 and SH4 only?
> > > Almost all SH4 systems out there have an FPU (unless special
> > > configurations
> > > are used). So I'd say if switching to soft-fp, then for SH-anything, not
> > > just SH3/SH4.
> > >
> > > If it yields some improvements for some users, I'm all for it.
> >
> > Yeah I just defaulted to SH3/SH4 conservatively because that's the only
> > hardware I have. (My main platform also happens to be one of these SH4
> > without an FPU, the SH4AL-DSP.)
Oh, wow, especially rare type!
> >
> > Once this is tested/validated on simulator, I'll happily simplify the
> > patch to apply to all SH.
The default sh-elf configuration has no multi-libs for SH3 and SH4 variants
without FPU (from what I can see). So it won't use soft-fp so much during
sim testing. So please change to soft-fp for sh*, not just SH3/SH4.
> >
> > > I think it would make sense to test it using sh-sim on SH2 big-endian and
> > > little endian at least, as that doesn't have an FPU and hence would run
> > > tests utilizing soft-fp.
> > >
> > > After building the toolchain for --target=sh-elf, you can use this to run
> > > the testsuite in the simulator:
> > >
> > > make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb}"
> > >
> > > (add make -j parameter according to you needs -- it will be slow)
> >
> > Alright, it might take a little bit.
> >
> > Building the combined tree of gcc/binutils/newlib masters (again
> > following [1])
> >
I have never built the toolchain using a combined tree. Like you said, it's
difficult to debug and so on. I've only built it separately and never had
any issues with this approach on multiple platforms/targets.
Here's an old proposed change to the simtest instructions to not use
combined trees:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20140815/fb38918e/attachment.bin
>
> This is almost certainly a poorly written pattern. I just fixed a bunch
> of these, but not this one. Essentially a recent change in the generic
> parts of the compiler is exposing some bugs in the SH backend.
The patterns were written and tested to the best of our knowledge at that
time many years ago. Nobody thought that we'll get a 2nd combine pass after
RA. Anyway, I'll have a look at the remaining patterns.
Sebastien, in the meantime you could also try out and test your changes on
the latest GCC 14 branch, which shouldn't have those issues.
Best regards,
Oleg Endo
