I did those changes 4 years ago and haven't done much recently.
Original problems were described in
https://bugs.llvm.org/show_bug.cgi?id=24109 and
https://bugs.llvm.org/show_bug.cgi?id=23897.
If I remember correctly, we have to make output code compatible with gcc on
Android.
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.
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.
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.
On Thu, Aug 29, 2019 at 12:34 PM Craig Topper <craig.topper at gmail.com>
wrote:
> 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?
>
> Thanks,
> ~Craig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190829/06a1a121/attachment.html>