<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6 Sep 2018, at 08:00, Dan Ravensloft via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, 3 Sep 2018 at 13:31, Tim Northover <<a href="mailto:t.p.northover@gmail.com" class="">t.p.northover@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So the next step is to debug where Mips is producing those TruncIntFP<br class="">
nodes. There'll be some constraint it's not checking or an unexpected<br class="">
node type, probably related to -msingle-float. I'm afraid I'm not sure<br class="">
what yet.</blockquote></div></div></div></div></div></blockquote><div><br class=""></div>FWIW, I'm not sure how well tested -msingle-float was on MIPS. I don't think we had any bots testing it.<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">I'm reasonably sure the function producing that node is lowerFP_TO_SINT_STORE in lib/Target/Mips/MipsISelLowering.cpp.<br class=""><br class="">The node before that function executes has an fp_to_sint node which seems to want to convert an i64 to an f32 which seems...rather odd to me, honestly. The PS2, for what it's worth, only has an i32 -> f32 instruction, so I think there's an impedance mismatch somewhere.</div></div></div></div></div></div></blockquote><div><br class=""></div><div>Did you mean those types to be the other way around? fp_to_sint is supposed to take a floating point type and produce an integer type so if you're seeing them backwards like this then that would definitely be a bug.</div><div><br class=""></div><div>If you're referring to the size mismatch though, that's ok within the IR and DAG nodes. There's no relationship between the size of the input and output. </div><br class=""><blockquote type="cite" class=""><div class="">
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>