Displaying 3 results from an estimated 3 matches for "bd91cf7a".
2013 Sep 20
3
[LLVMdev] LLD input graph handling proposal
...what file should be fed to Resolver next. For
example, it can detect from the atom counts whether Resolver need to exit
--{start,end}-group loop or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/bd91cf7a/attachment.html>
2013 Sep 20
0
[LLVMdev] LLD input graph handling proposal
On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> 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,
2013 Sep 20
6
[LLVMdev] LLD input graph handling proposal
Shankar and I discussed input file handling, and we came up with a design
that may greatly simplify the input file handling, while giving more
flexibility to developer to support complicated options, such as
--{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so
here's the idea:
1. We wouldn't probably want to let Resolver to handle the input graph
directly, for we