[LLVMdev] LLD input graph handling proposal
shankare at codeaurora.org
Fri Sep 20 19:23:13 PDT 2013
On 9/20/2013 8:37 PM, Nick Kledzik wrote:
> 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
> 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
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev