[llvm] r199244 - Reapply "LTO: add API to set strategy for -internalize"

Eric Christopher echristo at gmail.com
Wed Apr 2 14:35:28 PDT 2014


On Wed, Apr 2, 2014 at 1:50 PM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
>
> On Apr 2, 2014, at 13:22, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
>
>>> But isn't the C API stable?  Isn't it too late to roll back this change?
>>
>> I think we call it stable between releases. In the past at least I
>> have made changes knowing that that particular function was not in any
>> released version.
>
> Well, I don't really have an opinion here; I'm asking, not telling.  Nick,
> is ld64 using this yet?
>
> (If not, then your guess is better than mine whether there are out-of-tree
> users.)
>
> I'm still interested:  is there an actual policy here?

Stable between releases only. Some churn is allowed between.

I also missed this patch, I'm dubious as well as to the usefulness :)

Also I didn't see an ACK from anyone in the thread there on the
expansion of the API. I could be missing it though.

-eric

>
>> Even it we are now stuck with it in the C api, I would probably
>> implement it as close to the C api as possible. For example, please
>> don't keep the OnlyHidden option in createInternalizePass.
>
> Why?  It seems clean to me as is.  Rather than passing an enumerator where some values are invalid (but will never be passed), it's reduced to a Boolean flag.  Or do you think we should call createInternalizePass() even
> when LTO_INTERNALIZE_NONE?  Or what exactly?
>
> Sorry if I'm missing something obvious.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list