Quantcast

[PATCH] add unconditional support for @encode block descriptor string

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] add unconditional support for @encode block descriptor string

Blaine Garst
David Chisnall provided, as an option, an introspection field for blocks (const char *types) in the block literal data structure itself for use by the GNU runtime.

This was discussed and approved and integrated.

I am unconditionally adding this field instead to the read-only shared block descriptor data structure instead.  I am unconditionally re-using his BLOCK_HAS_OBJC flag bit.

Also, I am introducing a second new reserved field for block internal layout, initially set to NULL.

These need to be discussed in the ABI document and supported in the runtime.  Also, David's conditional support should be removed when he's ready.  I left it in to simplify understanding of the changes and, of course, to support his clients until he transitions his runtime to use the new location of the types field.

This diff reflects the already committed cleanup from my previous PATCH post today.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

CodeGen.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] add unconditional support for @encode block descriptor string

jahanian
Few comments.
Since hasIntrospection is no longer in use, you need to remove the  
option and all the code controlled by this flag.
Please run your test suite with the change for any regression.
Provide a test case  checking for new stuff being generated.

Our coding conversion is 1) no tab 2) limited to 80 columns (just in  
case).

Don't use {...}. Please remove '{' and '}'

- Fariborz


On Feb 18, 2010, at 5:34 PM, Blaine Garst wrote:

> David Chisnall provided, as an option, an introspection field for  
> blocks (const char *types) in the block literal data structure  
> itself for use by the GNU runtime.
>
> This was discussed and approved and integrated.
>
> I am unconditionally adding this field instead to the read-only  
> shared block descriptor data structure instead.  I am  
> unconditionally re-using his BLOCK_HAS_OBJC flag bit.
>
> Also, I am introducing a second new reserved field for block  
> internal layout, initially set to NULL.
>
> These need to be discussed in the ABI document and supported in the  
> runtime.  Also, David's conditional support should be removed when  
> he's ready.  I left it in to simplify understanding of the changes  
> and, of course, to support his clients until he transitions his  
> runtime to use the new location of the types field.
>
> This diff reflects the already committed cleanup from my previous  
> PATCH post today.
>
> <CodeGen.patch>_______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] add unconditional support for @encode block descriptor string

David Chisnall-2
In reply to this post by Blaine Garst
Hi Blaine,

On 19 Feb 2010, at 01:34, Blaine Garst wrote:

> Also, David's conditional support should be removed when he's ready.  I left it in to simplify understanding of the changes and, of course, to support his clients until he transitions his runtime to use the new location of the types field.


Feel free to remove it now.  

On a related note, passing any block type to @encode() currently returns "@?".  I wonder if we should change it to return the encoding of type of the block or, if this would break existing code (@? does already in quite a few cases that were written before blocks were introduced) provide some other mechanism for accessing this at compile time?

David
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] add unconditional support for @encode block descriptor string

jahanian

On Feb 19, 2010, at 10:09 AM, David Chisnall wrote:

> Hi Blaine,
>
> On 19 Feb 2010, at 01:34, Blaine Garst wrote:
>
>> Also, David's conditional support should be removed when he's  
>> ready.  I left it in to simplify understanding of the changes and,  
>> of course, to support his clients until he transitions his runtime  
>> to use the new location of the types field.
>
>
> Feel free to remove it now.
>
> On a related note, passing any block type to @encode() currently  
> returns "@?".  I wonder if we should change it to return the  
> encoding of type of the block or, if this would break existing code  
> (@? does already in quite a few cases that were written before  
> blocks were introduced) provide some other mechanism for accessing  
> this at compile time?

We can't change the encoding. Encoding for block is '@' for block and  
'?' for function type. Similar to function pointer type; except that
'^?' is used.

- fariborz

>
>
> David
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] add unconditional support for @encode block descriptor string

David Chisnall-2
On 19 Feb 2010, at 19:31, Fariborz Jahanian wrote:

> We can't change the encoding. Encoding for block is '@' for block and '?' for function type. Similar to function pointer type; except that
> '^?' is used.


1) ? actually signifies 'unknown type', not 'function type'
2) This is completely irrelevant to what I said.  I was talking about the return from doing something like:

typedef void(^foo)(id, void*);   @encode(foo);

This currently returns "@?" if foo is any block type, rather than the type encoding that we are storing with the block.  To get the block type encoding, we need to look up the type of a template block at run time, which prevents some optimisations when you test that two type encodings match, because neither is known at compile time (even though one actually is).

David

-- Sent from my PDP-11


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] add unconditional support for @encode block descriptor string

jahanian

On Feb 19, 2010, at 4:12 PM, David Chisnall wrote:

> On 19 Feb 2010, at 19:31, Fariborz Jahanian wrote:
>
>> We can't change the encoding. Encoding for block is '@' for block  
>> and '?' for function type. Similar to function pointer type; except  
>> that
>> '^?' is used.
>
>
> 1) ? actually signifies 'unknown type', not 'function type'
Granted you may not be looking at our Darwin source tree. But here it  
is:

else if (code == FUNCTION_TYPE) /* '?' */
     obstack_1grow (&util_obstack, '?');


>
> 2) This is completely irrelevant to what I said.  I was talking  
> about the return from doing something like:
>

Uncalled for. You need to be more clear so my comments become more  
'relevant'.

> typedef void(^foo)(id, void*);   @encode(foo);
>
> This currently returns "@?" if foo is any block type, rather than  
> the type encoding that we are storing with the block.  To get the  
> block type encoding, we need to look up the type of a template block  
> at run time, which prevents some optimisations when you test that  
> two type encodings match, because neither is known at compile time  
> (even though one actually is).

Fact of the matter is that we cannot change block's encoding at this  
time.
If you are using the same api to store encoding in block that @encode  
uses, you will get "@?". This is not very helpful. You need to write  
your
own encoding logic for block's detailed encoding to store in block's  
descriptor.

- Fariborz

>
>
> David
>
> -- Sent from my PDP-11
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] add unconditional support for @encode block descriptor string

David Chisnall-2
On 20 Feb 2010, at 01:21, Fariborz Jahanian wrote:

>> 1) ? actually signifies 'unknown type', not 'function type'
> Granted you may not be looking at our Darwin source tree. But here it is:
>
> else if (code == FUNCTION_TYPE) /* '?' */
>    obstack_1grow (&util_obstack, '?');

Perhaps someone should update the Apple documentation then:

http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html

Unless the people who write documentation only have access to the GNU source code - your documentation corresponds with our implementation...

>> typedef void(^foo)(id, void*);   @encode(foo);
>>
>> This currently returns "@?" if foo is any block type, rather than the type encoding that we are storing with the block.  To get the block type encoding, we need to look up the type of a template block at run time, which prevents some optimisations when you test that two type encodings match, because neither is known at compile time (even though one actually is).
>
> Fact of the matter is that we cannot change block's encoding at this time.
> If you are using the same api to store encoding in block that @encode uses, you will get "@?". This is not very helpful. You need to write your
> own encoding logic for block's detailed encoding to store in block's descriptor.

The code to create the encoding stored with the block already exists.  I wrote it months ago.  Blaine has now modified where it is stored and made it unconditional.  

What is lacking, is some way for users of clang to get this type encoding at compile time, without having to construct it themselves (or poke the semi-private block structure).  The simplest way of supporting this would be for @encode on a block type to return the type of the block, rather than a generic type.  

If this would break existing code, then we should consider adding a new @encode-like mechanism that can be used to get compile-time type encodings for block types.  If we're doing that, then it would be nice for the same mechanism to support type encodings for functions and methods.

David

-- Sent from my PDP-11


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Loading...