f128 in X86 backend

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?


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.