[lld] r223330 - Rewrite InputGraph's Group

[Rui Ueyama]

On Tue, Dec 9, 2014 at 1:33 AM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

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


I don't disagree, and I think I didn't oppose to your suggestion. I was
planning to create a "tag" (I don't know if I'm going to name the class as
such though) to leave markers in a list of input files. The reason why I
didn't do that in the previous patch is just to keep it small.


>  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).


Yes, we need something as a replacement for notifyProgress. I think we are
on the same page. And flattening the group is a first step.

Let's take an incremental approach as we planned. I have figured out the
cause of the last breakage, so after testing it on Linux and MacOS, let me
re-submit it.


>
> Shankar Easwaran
>
>
> --
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141209/3706debe/attachment.html>