On Fri, 7 Sep 2018 at 17:48, Tim Northover <t.p.northover at gmail.com> wrote:> I looked at your diffs and you've only changed one of the functions to > return SDValue(), you need to change lowerFP_TO_SINT itself too. The > one with the store is just there as an optimization; if it doesn't > trigger (because of your diff) then lowerFP_TO_SINT will still create > a bad node afterwards. >Thank you! With that, the four bugs I found in newlib's C code are dead. I think the lrint fix should be upstreamed right away; would you mind if I credited you in the patch? Unfortunately, we are not out of the woods yet. If memory serves me correctly, newlib has some assembly code in used for things like `_start` to bring up the C runtime, which GNU binutils accepts and Clang's assembler currently does not. I'll go build that so I'm not talking out of my ass. Cheers, Tim! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/79e75992/attachment.html>
On Fri, 7 Sep 2018 at 18:53, Dan Ravensloft <dan.ravensloft at gmail.com> wrote:> With that, the four bugs I found in newlib's C code are dead.Excellent!> I think the lrint fix should be upstreamed right away; would you mind if I credited you in the patch?Not at all. Thanks! Tim.
Alexander Richardson via llvm-dev
2018-Sep-08 22:32 UTC
[llvm-dev] Clang for the PlayStation 2
On Fri, 7 Sep 2018 at 18:53, Dan Ravensloft via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On Fri, 7 Sep 2018 at 17:48, Tim Northover <t.p.northover at gmail.com> wrote: >> >> I looked at your diffs and you've only changed one of the functions to >> return SDValue(), you need to change lowerFP_TO_SINT itself too. The >> one with the store is just there as an optimization; if it doesn't >> trigger (because of your diff) then lowerFP_TO_SINT will still create >> a bad node afterwards. > > > Thank you! > > With that, the four bugs I found in newlib's C code are dead. I think the lrint fix should be upstreamed right away; would you mind if I credited you in the patch? > > Unfortunately, we are not out of the woods yet. If memory serves me correctly, newlib has some assembly code in used for things like `_start` to bring up the C runtime, which GNU binutils accepts and Clang's assembler currently does not. > > I'll go build that so I'm not talking out of my ass.Hi Dan, In case you are interested in the baremetal libgloss bits, I made some changes to get that to compile with clang in <https://github.com/CTSRD-CHERI/newlib>. This also contains some unrelated changes to make it easier to use on QEMU MALTA and to build in CHERI pure-capability mode but the changes to the MIPS crt0 bits might be useful. I believe <https://github.com/CTSRD-CHERI/newlib/commit/2e686345f77a1b745e504ffdbdf012ec78fbfc74> and possibly some follow-up commits should be sufficient to compile libgloss with clang (at least for MIPS64). Alex> Cheers, Tim! > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
I've been somewhat busy with life over the past week, but I thought I'd come back to this all the same. On Sat, 8 Sep 2018 at 19:04, Dan Ravensloft <dan.ravensloft at gmail.com> wrote:> On Sat, 8 Sep 2018 at 15:01, Tim Northover <t.p.northover at gmail.com> > wrote: > >> At the moment I'm really quite confused about where that PseudoCVT_S_L >> is coming from though, the pattern generating it ought to be disabled. > > I commented out that pattern and Clang now complains about not being able > to select a valid instruction, but it doesn't segfault, suggesting that > pattern is definitely causing the crash. >I suppose I'll need to familiarise myself with the Clang pattern syntax anyway, because of the various major inconsistencies of the R5900 (it has no DMULT(U) or DDIV(U) instructions, which means it's not entirely MIPS III compliant). In other news, the "unexpected illegal type" assert is now fixed in trunk, which is the first step in a long, long path to bringing up support for this...*quirky*...architecture. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180916/7e8362f1/attachment.html>
I have a GitHub page containing my patches and a rough writeup of the issues I've encountered at https://github.com/ZirconiumX/ps2-clang-patches There's still a *lot* of work to be done before I'm going to consider upstreaming the backend, if at all, but I'll do my best to get bugfixes sorted quickly. On Sun, 16 Sep 2018, 18:10 xkrebstarx, <xkrebstarx at gmail.com> wrote:> Hi Dan, > > This is pretty interesting. Do you have a project page (or something) that > I can check out? > > On Sep 16, 2018, at 05:34, Dan Ravensloft via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I've been somewhat busy with life over the past week, but I thought I'd > come back to this all the same. > > On Sat, 8 Sep 2018 at 19:04, Dan Ravensloft <dan.ravensloft at gmail.com> > wrote: > >> On Sat, 8 Sep 2018 at 15:01, Tim Northover <t.p.northover at gmail.com> >> wrote: >> >>> At the moment I'm really quite confused about where that PseudoCVT_S_L >>> is coming from though, the pattern generating it ought to be disabled. >> >> I commented out that pattern and Clang now complains about not being able >> to select a valid instruction, but it doesn't segfault, suggesting that >> pattern is definitely causing the crash. >> > I suppose I'll need to familiarise myself with the Clang pattern syntax > anyway, because of the various major inconsistencies of the R5900 (it has > no DMULT(U) or DDIV(U) instructions, which means it's not entirely MIPS III > compliant). > > In other news, the "unexpected illegal type" assert is now fixed in trunk, > which is the first step in a long, long path to bringing up support for > this...*quirky*...architecture. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180916/7a9941c3/attachment.html>