On Thu, 6 Sep 2018, 16:31 Tim Northover, <t.p.northover at gmail.com> wrote:> > The PS2, for what it's worth, only has an i32 -> f32 instruction, so I > think there's an impedance mismatch somewhere. > > This is also a fairly common situation. If the operation can be > emulated with a reasonably small number of native instructions you can > often get LLVM to do that. > > In this case it would probably be a libcall though because it's quite > complex. LLVM would generate a call to __floatdisf, which will be > provided by compiler-rt (there are C implementations for all kinds of > floating-point operations there). > > You should see the same thing if you compile a function doing that > conversion with GCC. > > Cheers. > > Tim. >So I was rereading this; do you think the lowering function should instead emit a library call instead, then? If so, would you mind pointing me to a function which performs this, or otherwise give a high-level description of how this is done?>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180906/7642f73c/attachment.html>
On Thu, 6 Sep 2018 at 17:55, Dan Ravensloft <dan.ravensloft at gmail.com> wrote:> So I was rereading this; do you think the lowering function should instead emit a library call instead, then?I suspect so, though I'm not familiar enough with MIPS or the PS2 to be 100% sure -- checking what GCC does in this case would be good confirmation.> If so, would you mind pointing me to a function which performs this, or otherwise give a high-level description of how this is done?I *think* you should be able to just tell the lower function to ignore this case (maybe based on the types, maybe just because we're in SingleFloat mode, I'll need to read more code to be sure). Then the generic handling should get involved and expand it to a libcall if the operation isn't natively supported. Cheers. Tim.
Hi again, On Thu, 6 Sep 2018 at 17:55, Dan Ravensloft <dan.ravensloft at gmail.com> wrote:> If so, would you mind pointing me to a function which performs this, or otherwise give a high-level description of how this is done?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"). It looks like someone was enthusiastic enough to think this operation did actually deserve inlining (by TargetLowering::expandFP_TO_SINT) so instead of a libcall it produces a bunch of weird operations implementing that. I assume they're right, but haven't checked. 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. Cheers. Tim.
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>