jrtc27 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 concept, not a middle-end > / back-end 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 ever be doing; 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.
Libcall emission needs to know what AS to use for pointer arguments to things like __sync/__atomic implementations and various string-y mem*/str* functions. That's the main one that comes to mind from our experience in CHERI LLVM, and current LLVM just assumes that's AS0. 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
