On Thu, 6 Sep 2018 at 20:01, Tim Northover <t.p.northover at gmail.com> wrote:> I just did a very quick experiment where I made lowerFP_TO_SINT and > lowerFP_TO_SINT_STORE return SDValue() (which is the marker for "I > don't want to handle this").I just tried this, but the compiler still crashes with the same error. Maybe our experiments were different. To make it production-quality you'd want to predicate the changes I> made on Subtarget->isSingleFloat() I think (probably in combination > with the actual types, since f32 -> i32 ought to still be OK with the > existing code). The main annoyance there is that lowerFP_TO_SINT_STORE > is static rather than a member of MipsISelLowering so it doesn't have > access to Subtarget. Personally, I'd just make it a member function to > fix that. >lowerFP_TO_SINT_STORE is only ever called by lowerFP_TO_SINT, so I'm just passing single-floatness (we need a better name for that) as an argument to lowerFP_TO_SINT_STORE at the moment.> > Cheers. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/8b44f81e/attachment.html>
On Fri, 7 Sep 2018 at 07:38, Dan Ravensloft <dan.ravensloft at gmail.com> wrote:> I just tried this, but the compiler still crashes with the same error. Maybe our experiments were different.Strange. I only tested it on a simple reproducer rather than newlib: void foo(float *in, long long *out) { *out = *in; } $ clang -target mips64el-img-linux -mcpu=mips3 -S -o- -Os tmp.c [...] Is it possible you were hitting a different error with roughly similar output?> lowerFP_TO_SINT_STORE is only ever called by lowerFP_TO_SINT, so I'm just passing single-floatness (we need a better name for that) as an argument to lowerFP_TO_SINT_STORE at the moment.Are you sure? I see it being called by lowerSTORE. Cheers. Tim.
On Fri, 7 Sep 2018 at 16:59, Tim Northover <t.p.northover at gmail.com> wrote:> On Fri, 7 Sep 2018 at 07:38, Dan Ravensloft <dan.ravensloft at gmail.com> > wrote: > > I just tried this, but the compiler still crashes with the same error. > Maybe our experiments were different. > > Strange. I only tested it on a simple reproducer rather than newlib: > > void foo(float *in, long long *out) { > *out = *in; > } > $ clang -target mips64el-img-linux -mcpu=mips3 -S -o- -Os tmp.c > [...] > > Is it possible you were hitting a different error with roughly similar > output? >Both your simple reproducer and newlib give the same crash for me (Unexpected illegal type), though my build of LLVM doesn't list any direct symbols in the backtrace despite compiling in Debug mode. (maybe I missed a cmake option?)> > lowerFP_TO_SINT_STORE is only ever called by lowerFP_TO_SINT, so I'm > just passing single-floatness (we need a better name for that) as an > argument to lowerFP_TO_SINT_STORE at the moment. > > Are you sure? I see it being called by lowerSTORE. >You are correct, my apologies. So we're on the same metaphorical page, I've attached my git diffs; the build target I'm using is mips64el-scei-ps2. ps2-clang.diff applies to clang, while ps2-llvm applies to llvm, but that should be obvious. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/92bbeefd/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ps2-llvm.diff Type: text/x-patch Size: 2772 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/92bbeefd/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: ps2-clang.diff Type: text/x-patch Size: 587 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/92bbeefd/attachment-0003.bin>
On Fri, 7 Sep 2018 at 16:59, Tim Northover <t.p.northover at gmail.com> wrote:> $ clang -target mips64el-img-linux -mcpu=mips3 -S -o- -Os tmp.c >Actually, I just tried your flags; you're missing `-msingle-float`, which is what reproduces the crash on my end. Without it there is no problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180907/a929ae60/attachment.html>