[LLVMdev] PointerType API Change

[Christopher Lamb]

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*)
>>> 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)?

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:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- 
Mon-20071210/056223.html

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071217/5b7df076/attachment.html>