[PATCH] D64289: [OpenMP] Fix 128-bit long double support on target
Joel E. Denny via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sat Jul 6 16:30:39 PDT 2019
jdenny added inline comments.
================
Comment at: clang/lib/Sema/SemaOpenMP.cpp:1594
+ !Context.getTargetInfo().hasFloat128Type() &&
+ Context.getTargetInfo().getLongDoubleWidth() != 128) ||
(Ty->isIntegerType() && Context.getTypeSize(Ty) == 128 &&
----------------
ABataev wrote:
> jdenny wrote:
> > ABataev wrote:
> > > jdenny wrote:
> > > > ABataev wrote:
> > > > > Hmm, this look strange, at least. Seems to me, in this case the size of the long double is 128 bit (copied from the host), but device reports that it does not support 128 bit double. Seems to me, it is a problem with the device configuration. Why does the host translate long double to 128 bit fp, while the device translates it to 64 bit FP?
> > > > Sorry, I think I've misunderstood what's happening here, and my fix is probably wrong.
> > > >
> > > > For x86_64, the example from my patch summary fails as described there. Does that work for you?
> > > >
> > > > For powerpc64le, the reproducer I added to the test suite fails without this patch. Shouldn't it succeed?
> > > Still, seems to me like the problem with the device config, not the original check.
> > > Still, seems to me like the problem with the device config, not the original check.
> >
> > I'm not sure where to begin looking for that. Can you point me in the right direction? Thanks.
> You need to understand why host and device report different size of the type. Check how the device is configured in lib/Basic/Targets
Thanks for the pointer. I think I understand things a bit better now.
Without this patch's fix, the x86_64 example from this patch's summary fails while this patch's new x86_64 test case passes. The difference is the summary's example doesn't specify `-unknown-linux` after `x86_64`, and that's what sets `hasFloat128Type()` to true.
`powerpc64le-unknown-linux-gnu` does not have `__float128`, it seems. That's why this patch's new powerpc64le test case fails without this patch's fix.
It seems strange to me that the code we're commenting on originally looks for the source type to be either `__float128` or 128-bit `long double`, and it then requires the target to support `__float128`. It doesn't accept 128-bit `long double` support as sufficient. My intention in this patch was to extend it to accept either so that all the examples above compile. Is that too lenient? Am I misinterpreting what's happening?
As for your comment about 64-bit floating point in the device translation, I haven't seen that yet. Did I miss it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64289/new/
https://reviews.llvm.org/D64289
More information about the cfe-commits
mailing list