[cfe-dev] Constant CFString merge

[Jean-Daniel Dupas]

Thank you.

I will have a look at the 64 bit change, and I will try to do a  
consistent patch.


Le 23 août 08 à 21:10, Daniel Dunbar a écrit :

> Okay, sorry it took me a while to get to this. I pushed the parts of  
> the
> patch which rip out the constant CFString in CGObjCMac.cpp. I didn't
> add the 64-bit struct change because this is just going to assert in
> codegen. The 64-bit changes should go in as a consistent patch I
> think.
>
>
> - Daniel
>
>
> ----- Original Message ----
> From: Jean-Daniel Dupas <devlists at shadowlab.org>
> To: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
> Sent: Saturday, August 16, 2008 3:49:16 PM
> Subject: Re: [cfe-dev] Constant CFString merge
>
> 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.
>
>
>
> 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
>>
>