[LLVMdev] Removing AvailableExternal values in GlobalDCE (was Re: RFC: ThinLTO Impementation Plan)

[Teresa Johnson]

On Thu, Jun 4, 2015 at 11:27 AM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
>
>> On 2015-Jun-04, at 10:13, Teresa Johnson <tejohnson at google.com> wrote:
>>
>> On Thu, Jun 4, 2015 at 9:51 AM, Duncan P. N. Exon Smith
>> <dexonsmith at apple.com> wrote:
>>>
>>> In particular, I'm worried about GlobalDCE removing a *referenced*
>>> available_externally function, particularly if/when we stop inlining at
>>> the compile step when -flto.
>>
>> Ok, that makes sense. In that case, I agree that doing this for
>> ThinLTO imported functions is the right way to go. My initial approach
>> was to mark the functions that were ThinLTO-imported and check that
>> here. I think we will likely want to mark the imported functions as
>> such regardless, since we may want to apply different optimization
>> thresholds for imported functions, or at least use for debugging and
>> tracing, so we could consider using that approach here.
>>
>> Another possibility as you mentioned was to drop in a new pass in the
>> ThinLTO backend optimization pipeline just for this. Or perhaps the
>> GlobalDCE pass invocation could take a flag indicating that it should
>> remove the avail extern functions, that we can set in the ThinLTO
>> backend case. It seems like most of the code would be shared between
>> the current GlobalDCE and any new ThinLTO-specific version that
>> setting GlobalDCE up to do this optionally (either per-imported
>> function or with a configuration flag on the pass) made sense.
>
> Since the compiler is always free to delete available_externally
> functions, I think you could just add a pass to the -flto=thin pipeline
> that deletes all of them (referenced or not) -- it's just a single loop
> through all the functions deleting the bodies of those with the right
> linkage.  I imagine there are other pass pipelines that might want to do
> something similar.  I don't really like having GlobalDCE delete them
> (even behind a flag) because they aren't actually dead, and I think a
> separate pass makes it easier to test and all that.  (I haven't actually
> worked much with pass pipelines, though, so there's a chance I'm on my
> own here?)

Ok, sounds reasonable to do as a separate ThinLTO specific pass.

>
> You make an interesting point about applying different thresholds to
> imported functions, but is there any reason not to change all
> available_externally functions in the some way?  Moreover, it feels like
> thin-LTO's imported functions are a new source of functions with
> available_externally linkage, but otherwise they aren't interestingly
> different.
>

I suspect those cases are going to be due to summary information
recorded for the imported functions anyway, which we haven't defined
the format of yet anyway. So I think we can separate that from this
aspect of imported function handling, which can be based on the
linkage type alone, and defer that discussion until later.

Thanks for your help,
Teresa


-- 
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413