What to do with LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN?

[Nick Kledzik]

On Oct 31, 2013, at 8:35 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> Lots of deletes! That makes me smile.
> 
> Same here :-)
> 
>> Also, removing a C API call. That's never been in a release, right?
> 
> Correct. The feature was first implemented with an API close to what
> the gold plugin implements, but then I figure out I could use the
> existing LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN by moving a bit more
> work to the plugin. Fortunately the API has not been exposed in any
> release yet.
> 
>> @@ -162,6 +163,8 @@ LTOModule *LTOModule::makeLTOModule(MemoryBuffer
>> *buffer,
>> 
>>   TargetMachine *target = march->createTargetMachine(TripleStr, CPU,
>> FeatureStr,
>>                                                      options);
>> +  m->MaterializeAllPermanently();
>> +
>>   LTOModule *Ret = new LTOModule(m.take(), target);
>>   if (Ret->parseSymbols(errMsg)) {
>>     delete Ret;
>> 
>> Hah! You should talk to that guy who made LTO work with lazily loaded
>> bitcode. ;-)
> 
> Yes, this is the trade-off. I can be fixed with the address-taken bit
> proposal for example. For now the benefit of not having the extra C
> api in 3.4 seems worth it.
> 
>> +// For example: Internalizing a function with external linkage. Only if we
>> are
>> +// told it is only used from within this module, it is safe to do it.
>> 
>> "it is" -> "is it".
> 
> Where? Both occurrences look correct to me? (but I am not too sure
> about the comma).
> 
>> LGTM from me assuming that function has never been in a release before, but
>> I'd also like to see OtherNick sign off.
> 
> Thanks!
> 
> Nick Kledzik, is this OK with you?
Yes.

-Nick