AlexVlx wrote:
> > I'm not quite sure how to parse this comment, could you explain what you
> > have in mind here? The problem is precisely that the FE assumes 0 is fine /
> > picks it by default, which ends up into dangerzones when e.g. a target
> > happened to use 0 to point to private (stack). I feel as if I'm missing the
> > core of your comment though, so apologies in advance.
>
> I'm just saying that I don't think it makes any sense to add a concept of a
> default AS to LLVM. The "default" AS is a frontend-level concept about how to
> interpret source-level types , not an LLVM-level concept. LLVM would only
> need a default AS if it were inventing a memory allocation/operation from
> whole cloth, which is generally not something LLVM should be doing except in
> local memory; the only legitimate counter-example I can think of would be
> something like materializing a constant into constant global memory, in which
> case LLVM needs to assign the new constant an AS.
Thinking about this a bit more, is it not the case that today, we do have a _de
facto_ default AS in LLVM, if only by virtue of the fact that an unqualified
ptr ends up as a ptr to AS 0; unqualified ptrs are used all over the place /
the FE is pretty liberal in their employ? So, it's possible that a large part
of this pain is that we say stuff like the below:
```cpp
/// void*, void** in address space 0
union {
llvm::PointerType *UnqualPtrTy;
```
https://github.com/llvm/llvm-project/pull/88182
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
