================
@@ -1764,6 +1764,13 @@ class TargetInfo : public TransferrableTargetInfo,
return 0;
}
+ /// \returns Target specific flat ptr address space; a flat ptr is a ptr that
+ /// can be casted to / from all other target address spaces. If the target
+ /// exposes no such address space / does not care, we return 0.
----------------
AlexVlx wrote:
> > here's no such thing as LangAS::Generic, there's LangAS::Default.
>
> Right, so query the target address space map for that.
>
Ok, I queried LangAS::Default and I got
[this](https://github.com/llvm/llvm-project/blob/08de0b3cf54e4998799673f835e9a7d5ead8efab/clang/lib/Basic/Targets/AMDGPU.cpp#L65)
because of
[this](https://github.com/llvm/llvm-project/blob/08de0b3cf54e4998799673f835e9a7d5ead8efab/clang/lib/Basic/Targets/AMDGPU.cpp#L256).
What's next?
> The IR does not have the concept of a generic, flat, or no address space. 0
> is the "default address space", which has its own specific properties.
>
What are these specific properties and where are they documented? Also, 0
doesn't quite look like the default address space, at least not de jure, see
above; it's not even the default address space for all uses of AMDGPU.
> > this merely maintains the status quo, wherein everybody grabs an AS 0
> > pointer and hopes for the best.
>
> For the most part this isn't true, at least in llvm proper.
>
Sure, but this is in Clang, which pretty liberally uses things like
`getUnqualPtrTy` and hopes it will work. Elsewhere you are essentially arguing
for exactly the same thing, namely the FE should just use 0 unconditionally. I
am saying that is wrong in general, and the next best thing is to query the
target if it happens to have any opinions regarding what the AS one should use
everywhere is. Just like we're already asking if it has any opinions about
something far more niche, namely vtable ptrs), and then revert to the status
quo which is use 0. In Clang. Because, otherwise, your request for the FE to
"just do the right thing" ends up unsolvable.
https://github.com/llvm/llvm-project/pull/95728
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
