[LLVMdev] LLD input graph handling proposal

[Rui Ueyama]

On Fri, Sep 20, 2013 at 3:42 PM, Shankar Easwaran
<shankare at codeaurora.org>wrote:

> Hi Nick,
>
>
> On 9/20/2013 5:29 PM, Nick Kledzik wrote:
>
>> Rui,
>>
>> I like this in general, but have a few questions.
>>
>> On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>>  2. We would instead add a new method nextFile() to LinkingContext, which
>>> returns a new file from which Resolver should try to resolve undefined
>>> symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver
>>> calls nextFile() repeatedly to link until nextFile() returns a null value.
>>>
>>> 3. Resolver will notify Linking Context when (A) all undefined symbols
>>> are resolved (success), or (B) it detects it's in an infinite loop in which
>>> it cannot resolve any symbols anymore (failure). Linking Context will do
>>> whatever it thinks appropriate for the event notification.
>>>
>> How does the Resolver detect an infinite loop?  As in the example below,
>> it is supposed to keep getting a,b,c,a,b,c…    At some point, no more
>> undefines are being fulfilled by a,b,c,a,b,c…, but how does the resolver
>> know that the files are repeating, to know to tell the InputGraph to move
>> on?
>>
> nextFile could pass the current resolver state at the time when its
> called, the linkingcontext can return the next file to be processed as
> below :-
>
> nextFile(currentResolverState) :-
>
> a) Returns the next file if the current node is not a group node
> b) Returns the next file in the group node, if the current node is a group
> node and the resolver state states undefined /weak / shared library atoms
> were added.
> c) Returns the start file in the group node, if the resolver state states
> undefined/weak/shared library atoms were added
> d) If the state is unchanged, no symbols were added exit the group and
> move to the next node.
>

So you prefer detecting loop in Linking Context based on the information
it's passed by Resolver, over letting Resolver to do that? Not sure if we
want the additional information sorted by atom type, but that way should
work too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/a7f35b87/attachment.html>