<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr">On Thu, 6 Sep 2018, 16:35 Daniel Sanders, <<a href="mailto:daniel_l_sanders@apple.com">daniel_l_sanders@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On 6 Sep 2018, at 08:00, Dan Ravensloft via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-5748612700847401847Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 3 Sep 2018 at 13:31, Tim Northover <<a href="mailto:t.p.northover@gmail.com" target="_blank" rel="noreferrer">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>
nodes. There'll be some constraint it's not checking or an unexpected<br>
node type, probably related to -msingle-float. I'm afraid I'm not sure<br>
what yet.</blockquote></div></div></div></div></div></blockquote><div><br></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></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Well, now we have hardware, if all of one machine, where it's worth testing. I'm happy to try it myself if needed, though rigging it up to happen automatically would be difficult.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>I'm reasonably sure the function producing that node is lowerFP_TO_SINT_STORE in lib/Target/Mips/MipsISelLowering.cpp.<br><br>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></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></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, my mistake; I got confused by the direction of the arrows on the graph, they're pointing to their parents, but I thought they were pointing to their children.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></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><blockquote type="cite"><div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" rel="noreferrer">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></blockquote></div></div></div>