AlexVlx wrote:
> I think the point is there are two things going on here that people think of
> as unqualified:
>
> 1. "Give me a pointer that's whatever `void *` is"
> 2. "Give me a pointer in some address space just so I can put a global in
> some metadata"
>
> The vast majority of the time we're talking about 1, which is what most
> people would think of unqualified as meaning. #93601 / #93914 are about the
> three special cases that are case 2 above. But those are a special case, and
> normally when people say unqualified they mean "default" address space /
> `void *`.
Building on the above, let me add a bit more colour I should have added from
the get go:
- More often than not, for case (1) above, folks probably want (knowingly or
not) a `void*` that "works",
with no actual concern for the address space (the "default");
- As an example, for targets which model themselves / draw inspiration from
e.g. OpenCL, this'd be a
generic / flat pointer, but there's no way for the FE to query that from
the target (today?), and that
information isn't really observably encoded in something like the
DataLayout; if we were to add
something like that, then unqualified would / should correspond to this,
IMHO (could well happen to be 0
in practice);
- We have targets that map `LangAS::Default`oddly / differently from the
above expectation, and hence it
appeared profitable to have `UnqualPtrTy`, which is a generally useful /
everywhere usable pointer type,
be different from `Int8PtrTy` / `VoidPtrTy` which are pointer types which
correspond to the target's
default (perhaps I am being overly cautious here though).
Having said that, this change is somewhat inert at the moment beyond carving
out the name / making it shorthand for calling `getUnqual()`. In the future, we
could either:
- extend DL to expose a target's flat/generic AS
- (more intrusive / might be infeasible) make unqualified `ptr`s be
generic/everywhere usable in IR, without
the target exposing a flat/generic AS, letting the target figure out the
legality of e.g. this or that ascast.
https://github.com/llvm/llvm-project/pull/94388
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
