[cfe-dev] Constant CFString merge

[Jean-Daniel Dupas]

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
>