Christopher,> The API for getting PointerType objects has just changed to make > Embedded C address space information explicit. The old semantics of > PointerType::get() now apply to PointerType::getUnqual(), which > returns a pointer in the generic address space. PointerType::get() now > requires both a type and an address space.What is the reason of such change? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
On Dec 16, 2007, at 10:22 PM, Anton Korobeynikov wrote:> Christopher, > >> The API for getting PointerType objects has just changed to make >> Embedded C address space information explicit. The old semantics of >> PointerType::get() now apply to PointerType::getUnqual(), which >> returns a pointer in the generic address space. PointerType::get() >> now >> requires both a type and an address space. > What is the reason of such change?Sorry for not providing that. Here's the conversation with Chris:> On Dec 12, 2007, at 1:32 AM, Christopher Lamb wrote: > >> On Dec 11, 2007, at 4:12 PM, Chris Lattner wrote: >> >>> Making the address space default to zero is convenient, but >>> dangerous. This means that xforms that play with pointers need >>> to be >>> very careful to propagate this info in some cases. Do you think >>> this >>> is the best way to go? Do many clients of PointerType::get need to >>> be aware of addr spaces? >>> >> >> I'm going to add a new method for getting a pointer type >> 'PointerType::getUnqual()' that only takes an element type, the >> standard 'PointerType::get()' will take both an element type and >> address space with no default values. This should at least make it >> explicit in the code which clients do not pass in an address space. >> There are currently many clients, so this should help make the work >> incremental. > > Excellent idea, > > -Chris >-- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071216/f0662bc8/attachment.html>
Hi Anton, On 2007-12-17, at 01:22, Anton Korobeynikov wrote:> Christopher, > >> The API for getting PointerType objects has just changed to make >> Embedded C address space information explicit. The old semantics of >> PointerType::get() now apply to PointerType::getUnqual(), which >> returns a pointer in the generic address space. PointerType::get() >> now requires both a type and an address space. > > What is the reason of such change?The rationale is in this thread from llvm-commits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071210/056257.html — Gordon
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. 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(...). Torvald On Monday 17 December 2007, Christopher Lamb wrote:> On Dec 16, 2007, at 10:22 PM, Anton Korobeynikov wrote: > > Christopher, > > > >> The API for getting PointerType objects has just changed to make > >> Embedded C address space information explicit. The old semantics of > >> PointerType::get() now apply to PointerType::getUnqual(), which > >> returns a pointer in the generic address space. PointerType::get() > >> now > >> requires both a type and an address space. > > > > What is the reason of such change? > > Sorry for not providing that. Here's the conversation with Chris: > > On Dec 12, 2007, at 1:32 AM, Christopher Lamb wrote: > >> On Dec 11, 2007, at 4:12 PM, Chris Lattner wrote: > >>> Making the address space default to zero is convenient, but > >>> dangerous. This means that xforms that play with pointers need > >>> to be > >>> very careful to propagate this info in some cases. Do you think > >>> this > >>> is the best way to go? Do many clients of PointerType::get need to > >>> be aware of addr spaces? > >> > >> I'm going to add a new method for getting a pointer type > >> 'PointerType::getUnqual()' that only takes an element type, the > >> standard 'PointerType::get()' will take both an element type and > >> address space with no default values. This should at least make it > >> explicit in the code which clients do not pass in an address space. > >> There are currently many clients, so this should help make the work > >> incremental. > > > > Excellent idea, > > > > -Chris > > -- > Christopher Lamb