[lld] r223330 - Rewrite InputGraph's Group

Shankar Easwaran shankare at codeaurora.org
Mon Dec 8 08:33:25 PST 2014


On 12/7/2014 7:19 PM, Rui Ueyama wrote:
> On Fri, Dec 5, 2014 at 9:13 AM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
>
>> Hi Rui,
>>
>> They key idea was to flatten the graph but also use tags to know about
>> some control flags, that change linker operation(group begins / ends (or)
>> what input files are part of as-needed).
I think you missed addressing this issue, the writer needs to know where 
the group starts and where the group ends to print the Map file apppriately.

I would prefer to use tags, or could you let me know what would be the 
alternative process other than going through the input elements twice.

>> The LinkingContext would need to  know about what happens in the resolver
>> per input element (that would contain a tag and a file locator).
>>
>> These two requirements are really needed for the linker Gnu flavor for its
>> operation and the infrastructure needs to be scalable as well.
>>
> Yes, these are obvious needs. I have of course no intention to remove
> --as-needed from the linker.
>
> As you might have noticed, notifyProgress is not the only way that we can
> use for the core linker to the LinkingContext. It, for example, doesn't
> have to be real-time. Instead of telling the progress for each file, we
> could accumulate that information and pass it to the next pass.
>
While its possible in the current infrastructure to handle --as-needed,  
I think we need to implement the necessary functions to call into the 
linking context or to query the resolver as part of this patch(as a 
replacement to notifyProgress).

Shankar Easwaran

-- 

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation




More information about the llvm-commits mailing list