[LLVMdev] LLD input graph handling proposal

[Shankar Easwaran]

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.

Thanks

Shankar Easwaran

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