================
@@ -312,3 +313,26 @@ void clang::takeAndConcatenateAttrs(ParsedAttributes
&First,
if (Second.Range.getEnd().isValid())
First.Range.setEnd(Second.Range.getEnd());
}
+
+LangAS ParsedAttr::asLangAS() const {
+ switch (getParsedKind()) {
+ case ParsedAttr::AT_OffloadGlobalAddressSpace:
+ return OffloadGlobalAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_OffloadGlobalDeviceAddressSpace:
+ return OffloadGlobalDeviceAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_OffloadGlobalHostAddressSpace:
+ return OffloadGlobalHostAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_OffloadLocalAddressSpace:
+ return OffloadLocalAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_OffloadPrivateAddressSpace:
+ return OffloadPrivateAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_OffloadConstantAddressSpace:
+ return OffloadConstantAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_OffloadGenericAddressSpace:
+ return OffloadGenericAddressSpaceAttr::getLangAS(*this);
+ case ParsedAttr::AT_HLSLGroupSharedAddressSpace:
+ return LangAS::hlsl_groupshared;
+ default:
+ return LangAS::Default;
+ }
+}
----------------
elizabethandrews wrote:
>> Would you find it strange if I suggested that we just use the CUDA
>> attributes for SYCL? If so, how would that be different from using the
>> OpenCL spellings?
I understand where you are coming from but I don't think I would find it
strange if the attributes are semantically doing the same thing, especially if
we are reusing CUDA/openCL attributes. I would definitely add a SYCL spelling
for the attribute for users to use in SYCL code going forward but I personally
wouldn't disallow the use of the old spellings if we weren't changing behavior.
>>The mapping from (logical) SYCL address spaces to the (physical) address
>>spaces of the device targets should vary by target device.
I agree. This was how it was prior to the second commit in this PR. It depended
on LangOpts. I may have misunderstood your request but I modified this behavior
to use spellings instead based on your request during offline conversations.
>>My goal is 1) clarity of intent, and 2) flexibility to handle SYCL concerns
>>separately from OpenCL concerns.
As long as the mapping is done based on LangOpts, this is possible.
https://github.com/llvm/llvm-project/pull/200849
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
