[LLVMdev] LLD input graph handling proposal

[Shankar Easwaran]

Hi Nick,

On 9/20/2013 8:37 PM, Nick Kledzik wrote:
> Shankar,
>
> I think your proposal and mine are pretty much the same.  The 
> difference is passing back info to the InputGraph as a parameter in 
> nextFile() vs as a separate method call.    My original draft email 
> had a parameter in nextFile(), but it seemed a little confusing 
> because the information was referring to the previous file.  That is, 
> if the current resolver state has newDefinedAtoms, that really means 
> the last file (returned by nextFile()) caused new atoms to be added.
>
> In your ResolverState you have bits for all the kinds of atoms added. 
>  Is all that needed?  I think all the InputGraph needs to know is if 
> the last file was used.  A group is scanned repeatedly until there is 
> one complete pass in which no new files were used.
Yes just bits, to say whether it was used and contributed undefined 
atoms or Defined Weak atoms.
>
> Also, is nextFile() going to be in InputGraph and directly accessed by 
> the Resolver?  Or is nextFile in LinkingContext (which forwards it to 
> the InputGraph)?  I assume the later.

Yes the latter.
>
> Currently, the Resolver has buildInitialAtomList() and 
> resolveUndefines() which matches the way darwin links.  I assume part 
> of this change is to unify those two methods by just have one loop 
> that uses nextFile().
>
Yes. This also makes the resolver totally dependent on 
InputGraph/LinkingContext.

> Given that nextFile() is basically an iteration mechanism, perhaps we 
> can make it conform to C++11 iterators.

Yes, its an iterator. I was thinking on a second pass around the same. 
nextFile could work on a range of files, until it reaches a ControlNode 
in the InputGraph.

>  The one issue is the feedback of whether the file was used or not.  A 
> separate notifyFileAddedContent() method (instead of a parameter to 
> nextFile()) could fix that.  And if Resolver::doFile() called 
> linkingContext.notifyFileAddedContent() for every file used (even 
> object files), then the Resolver algorithm would look like:

I like notifyFileAddedContent. makes it more extendable and can be 
called from anywhere in the resolver after the call from nextFile.

I will start implementing this solution. make
Thanks

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-dev/attachments/20130920/d78f2d6d/attachment.html>