[LLVMdev] PointerType API Change
christopher.lamb at gmail.com
Mon Dec 17 11:45:15 PST 2007
On Dec 17, 2007, at 2:51 AM, Torvald Riegel wrote:
> 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*)
>>> 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
>>> 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
>>> address space", then one should even be able to continue to use
>>> 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
> incremental upgrade path.
> I know that this approach might not really encourage developers to
> address space issues. Are they important and widespread enough that
> everybody should (or is proper address space handling trivial enough)?
I don't have particularly strong feelings about this, however Chris
did mention that he would like passes to take address spaces into
account. Handling them properly is pretty trivial, I believe.
Take a look at the this exchange on LLVM commits for some background
discussion on this:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev