<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">I did those changes 4 years ago and haven't done much recently.</div><div class="gmail_default" style="font-size:small">Original problems were described in <a href="https://bugs.llvm.org/show_bug.cgi?id=24109">https://bugs.llvm.org/show_bug.cgi?id=24109</a> and <a href="https://bugs.llvm.org/show_bug.cgi?id=23897">https://bugs.llvm.org/show_bug.cgi?id=23897</a>.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If I remember correctly, we have to make output code compatible with gcc on Android.</div><div class="gmail_default" style="font-size:small">When I did it, I followed the pattern used for other targets, by keeping f128 type "legal" and then "softening" some instructions to library calls. I found that code generator model strange too. I tried a couple times to clean up the type legalization loop, but got into infinite loops or not able to handle some corner cases. I finally concluded that it was beyond my project scope to change the type legalization model.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If the type legalization model has been improved, maybe it is possible to simplify the softening process, for f128 and other types. I haven't followed recent changes.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If you make changes to x86_64 f128, please keep me updated. We don't always catch regressions with llvm f128 unit tests. Sometimes I found regressions by running the Android x86_64 target tests.</div><div class="gmail_default" style="font-size:small">  <br></div><div class="gmail_default" style="font-size:small">On Thu, Aug 29, 2019 at 12:34 PM Craig Topper <<a href="mailto:craig.topper@gmail.com">craig.topper@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Does anyone know why f128 is partially implemented by running some operations through float softening in the type legalizer? The type is marked Legal, but then the TypeAction is forced to SoftenFloat. Why can't this be implemented instead by using ExpandNode in LegalizeDAG for the operations that need library calls?</div><div><br></div>Thanks,<br clear="all"><div><div dir="ltr">~Craig</div></div></div>
</blockquote></div></div>