Re: PointerType API Change

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Anton Korobeynikov
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.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Christopher Lamb

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




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Gordon Henriksen-3
In reply to this post by Anton Korobeynikov
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Torvald Riegel-3
In reply to this post by Christopher Lamb
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Christopher Lamb

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.

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


--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Torvald Riegel-3
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 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:

--
Christopher Lamb




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: PointerType API Change

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev