[LLVMdev] PointerType API Change

[Torvald Riegel]

On Monday 17 December 2007, Christopher Lamb wrote:
> On Dec 17, 2007, at 1:22 AM, Torvald Riegel wrote:
> > Would it be possible to keep get() unchanged, with a default
> > behaviour, plus
> > a warning? Otherwise everybody (assuming everybody gets type void*)
> > will
> > have to update their LLVM passes, and either maintain two versions
> > of the
> > passes or require their clients to use a certain LLVM version.
>
> AFAIK API compatibility is not guaranteed across LLVM point releases,
> so I believe clients are tied to a specific version of LLVM in any case.
>
> > Then passes
> > could be "address-space-safe" or not. If the default parameter
> > value for
> > get() could be a unique ID for "not specified" instead of "the default
> > address space", then one should even be able to continue to use get()
> > isntead of sth like getQual(...).
>
> The reason for the change was to make it absolutely clear in the
> source where address space qualifiers are preserved/added or stripped
> from the pointer type. Allowing clients to use get() and then
> dynamically track "undefined" address spaces under the hood is
> counter to this goal.

Informally, what I'd like to have is getUnqual() semantics as default for 
get(), thus giving you the same safety properties but without having to 
change all occurrences. If clients do handle address spaces, they could use 
getQual(...) and getUnqual().
I don't see how this would be counter to your goals. If a module with 
address spaces comes along, the pass could still abort and thell the user 
that it doesn't know how to handle this, which would give users a complete 
incremental upgrade path.

I know that this approach might not really encourage developers to consider 
address space issues. Are they important and widespread enough that 
everybody should (or is proper address space handling trivial enough)?

Torvald