aaron.ballman added inline comments.
================ Comment at: clang/docs/HLSLSupport.rst:150-152 +HLSL has a ``precise`` qualifier that behaves unlike anything else in the C +language. The support for this qualifier in DXC is buggy, so our bar for +compatibility is low. ---------------- beanz wrote: > aaron.ballman wrote: > > Is it worth supporting at all (I know you want source compatibility...)? > > Type system changes are generally expensive and invasive, largely because > > changing the type system in C++ is complicated. For example, does this > > qualifier impact overload sets or template specializations? Does it get > > name mangled? That sort of thing. > Unfortunately we do need to implement it to some degree. In DXC it is > implemented as an attribute rather than a qualifier, so it shouldn't impact > overloads, template specialization or mangling. > > I call it a qualifier here because it is syntactically more like a qualifier, > but I'm honestly not sure how we should implement it. In DXC, we emit IR > metadata denoting the underlying value as "precise", then in an IR pass > propagate disabling fast math. > Unfortunately we do need to implement it to some degree. In DXC it is > implemented as an attribute rather than a qualifier, so it shouldn't impact > overloads, template specialization or mangling. Okay, I kind of figured you needed it. > I call it a qualifier here because it is syntactically more like a qualifier, > but I'm honestly not sure how we should implement it. In DXC, we emit IR > metadata denoting the underlying value as "precise", then in an IR pass > propagate disabling fast math. This smells more like an attribute than a qualifier to me, but I'd like to see if I understand first (please ignore if I get syntax wrong): ``` // Initialization precise float f = 1.0 / 3.0 * sinf(3.14f); // value computation is precise // Assignment f = 1.0 / 3.0 * sinf(3.14f); // value computation is NOT precise (not a declaration)? // RHS of expression float f2 = f * 2.0; // value computation is NOT precise (f2 is not marked precise)? ``` ================ Comment at: clang/docs/HLSLSupport.rst:197 +* Any use of the ``virtual`` keyword +* Most features C++11 and later ---------------- beanz wrote: > aaron.ballman wrote: > > Same question here as above with C on whether we expect to support those as > > extensions or diagnose them as invalid. > I didn't really answer that above. I am inclined to do a mix of both. > Anything that we can support and lower I'd like to treat as extensions. Some > things we just can't. > > We don't currently have any way to allocate memory dynamically, so there's > really no way to support new/delete. RTTI and exceptions are another case > where we just don't have the support we would need in the driver > specifications. Okay, that seems reasonable enough. Should we issue "this is a Clang extension" diagnostics in the places where you're supporting something as an extension? Also, I presume you intend to add error diagnostics for all the cases that are not supported? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123278/new/ https://reviews.llvm.org/D123278 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
