[cfe-dev] Constant CFString merge

[Jean-Daniel Dupas]

An other version of the patch that revert back the type of the isa  
field to "const int *", but keep unsigned value for other fields (as  
CoreFoundation declare them as unsigned values).
I also drop the SmallVector to use a static array.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfstrings.diff
Type: application/octet-stream
Size: 8689 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080817/f69566f5/attachment.obj>
-------------- next part --------------


Le 16 août 08 à 09:04, Jean-Daniel Dupas a écrit :

>
>
> Le 16 août 08 à 01:58, Daniel Dunbar a écrit :
>
>> Okay, that makes sense. The only issue then is that the runtime
>> doesn't
>> get control over what the constant string class reference is called,
>> but since
>> GNU and NeXT both use the same name that doesn't seem to be an issue.
>>
>> RE: The patch:
>>
>> (1) In ASTContext::getCFConstantStringType there is really no need
>> to use
>> a SmallVector here, even if the size is changing by one. Also some of
>> the comments re: the type are incorrect... and why did you change
>> the ones
>> you did (the str I understand, but why unsigned -> signed or const
>> int* -> int*)?
>>
>> I think it makes more sense to change this file when someone does
>> UTF-16
>> support.
>
> This is to match closely the CoreFoundation declaration that is like
> this:
>
> struct  {
>     uintptr_t _cfisa;
>     uint8_t _cfinfo[4];
> #if __LP64__
>     uint32_t _rc;
> #endif
>   void *buffer;
>   CFIndex length;
> } CFRuntimeBase;
>
> But if you think we should keep the previous decaration, I don't see
> any problem about it, as long as they are equivalents.
>
>> (2) The NeXT runtime should still set the section on constant
>> cfstrings.
>
> Actually, both the builtin___CFStringMakeConstantString and the objc
> constant string generator store cf strings into"__DATA, __cfstring" in
> GCC.
> And so, GetAddrOfConstantCFString() already set it to this value. Do
> you think about something else ?
>
>
> I have another question about string generation.
> Actually, if you compile the code below using GCC, it create only
> one .ascii "Hello World !" constant and use it for both the constant
> string and the CFString data.
> Should we implement this optimization too, or is there a reason we
> generate you own private c string for each CFString ?
>
> -------------
> CFStringRef test() {
>   return CFSTR("Hello World !");
> }
>
> const char *test2() {
>   return "Hello World !";
> }
> -------------
>
>
>> - Daniel
>>
>>
>>
>> ----- Original Message ----
>> From: Jean-Daniel Dupas <devlists at shadowlab.org>
>> To: Daniel Dunbar <daniel at zuster.org>
>> Cc: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
>> Sent: Friday, August 15, 2008 1:40:01 PM
>> Subject: Re: [cfe-dev] Constant CFString merge
>>
>>
>> Le 15 août 08 à 20:59, Daniel Dunbar a écrit :
>>
>>> One problem here is how to handle emission of constant CFStrings  
>>> when
>>> not in Objective-C mode.
>>>
>>> I don't really want to always have a CGObjCRuntime object around,
>>> because
>>> the runtime is likely to want to add data to the module which should
>>> only
>>> happen for ObjC files, and conditionalizing this in the
>>> CGObjCRuntime is
>>> somewhat gross.
>>
>> In the patch, the obj-c runtime is not required. The implementation  
>> is
>> splitted into ASTContext (for the type declaration) and CodeGen (for
>> GetAddrOfConstantCFString()).
>> The apple objc runtime only call GetAddrOfConstantCFString(), and  
>> when
>> compiling a C file, you don't have to create an objc runtime, you can
>> just call GetAddrOfConstantCFString() of CodeGenModule.
>>
>>> This made me think that perhaps having separate methods is not so
>>> bad.
>>> There is also the complexity that gcc supports several options which
>>> change
>>> how constant strings are handled, but these options should probably
>>> not
>>> conflict with how __builtin___CFStringMakeConstantString is
>>> implemented.
>>> I'm not yet sure how these options interact, however.
>>
>> I don't know a lot of options that change the way objc/cf strings are
>> generated. I'm only aware about:
>>
>> -fconstant-cfstrings
>> and
>> -fconstant-string-class
>>
>> Both functions does not change the way constant strings are created,
>> but define if an alternative way should be used (instead of
>> GetAddrOfConstantCFString()).
>>
>> If the first option (-fconstant-cfstrings ) is not defined, the CFSTR
>> macro definition create function call instead of call to the builtin
>> function.
>>
>> The second option:
>>
>> - if -fconstant-cfstrings is specified, it override this setting, and
>> constant cfstrings are generated.
>> - if -fconstant-cfstrings is not specified, obj string generation
>> should create a constant string specific to each runtime
>> (NSConstantString by default for the next runtime), so it does not  
>> use
>> constant CFString generation at all.
>>
>> And so, I don't see any option that change the way
>> GetAddrOfConstantCFString() should behave (but maybe I miss
>> something).
>>
>>> I think perhaps we should split the UTF-16 fix, which definitely
>>> should be done
>>> for both, from the reorganization.
>>>
>>> - Daniel
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>