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
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>
On Mon, 17 Dec 2007, Christopher Lamb wrote:>> 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.My opinion is that we don't want to have "second rate" features that are subtly broken. In fact, Christophers conversion from using PointerType::get to use PointerType::getUnqual did expose several bugs (which were easy to fix once found). Unfortunately, we don't guarantee API stability across llvm releases, so I think that this breakage is reasonable. It is also really trivial to hack around this locally while in migration: just default the address space specifier in PointerType::get() to default to 0 in your local tree. -Chris -- http://nondot.org/sabre/ http://llvm.org/