asavonic added inline comments.
================
Comment at: clang/lib/Basic/Targets/X86.cpp:385
- if (!HasX87) {
- if (LongDoubleFormat == &llvm::APFloat::x87DoubleExtended())
- HasLongDouble = false;
- if (getTriple().getArch() == llvm::Triple::x86)
- HasFPReturn = false;
- }
+ if (!HasX87 && getTriple().getArch() == llvm::Triple::x86_64 &&
+ LongDoubleFormat == &llvm::APFloat::x87DoubleExtended())
----------------
pengfei wrote:
> asavonic wrote:
> > I see that D112143 changed the ABI so that FP return values do not use x87
> > registers on i386. Therefore HasFPReturn flag can be removed.
> >
> > However, operations with long double (x87 80-bit) should still be
> > unsupported on both targets, because IIRC there is no SSE equivalent for
> > them. GCC compiles them as soft-fp when -mno-x87 is set, but I haven't
> > found 80-bit soft-fp implementation in LLVM.
> > ```
> > long double baz(long double a, long double b) {
> > return a + b;
> > }
> > ```
> >
> > ```
> > baz:
> > [...]
> > call __addxf3
> > ```
> > For some reason GCC only does this for for i386 target, for x86_64 it just
> > emits the diagnostic about disabled x87.
> Thanks for looking at this patch.
> I don't think we need to exclude f80 particularly. IIUC, backend tries all
> possible ways to lower a given operation. Lowering to library is always the
> last choice. So the behavior is not confined to soft-fp.
> It's true LLVM has problems with f80 lowering without x87. I commented it in
> D112143 and hope D100091 will fix them. We don't need to bother to change it
> again in future.
>
> > For some reason GCC only does this for for i386 target, for x86_64 it just
> > emits the diagnostic about disabled x87.
> I think the root reason is the difference in ABI. 32-bits ABI allows passing
> and returning f80 without x87 registers while 64-bits doesn't. So we have to
> and only need to disable it for x86_64.
> I don't think we need to exclude f80 particularly. IIUC, backend tries all
> possible ways to lower a given operation. Lowering to library is always the
> last choice. So the behavior is not confined to soft-fp.
> It's true LLVM has problems with f80 lowering without x87. I commented it in
> D112143 and hope D100091 will fix them. We don't need to bother to change it
> again in future.
Right, but can LLVM lower any x87 80-bit fp operations other than return values?
If it cannot, then I think a source level diagnostic is a good thing to have.
Otherwise the only handling we have is the codegen crash with "x87 register
return with x87 disabled" and no source-level context.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D114162/new/
https://reviews.llvm.org/D114162
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
