What to do with LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN?

[Rafael Espíndola]

> 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?

> Nick

Cheers,
Rafael