Rafael Avila de Espindola via llvm-dev
2016-Dec-13 20:13 UTC
[llvm-dev] LLD status update and performance chart
Hal Finkel <hfinkel at anl.gov> writes:> >> Please tell me what you think about how reusable components would be >> like. Which parts of the linker can be reusable components? Is that >> really feasible? > As far as I'm concerned, your response, "That said, I think the current our 'API' to allow users call our linker's main function hit the sweet spot. I know at least a few LLVM-based language developers who want to eliminate external dependencies and embed a linker to their compilers. That's a reasonable usage, and I think allowing them to pass a map from filename to MemoryBuffer objects makes sense, too. That would be done without affecting the overall linker architecture. I don't oppose to that idea, and if someone wrote a patch, I'm fine with that" is perfectly appropriate. We need to guide these discussions with use cases, and that's the use case that's been provided so far. > > Longer term, we also should take a serious look at how to unify the functionality in LLD with that in our JIT runtime linker. Having two linkers in the LLVM project, one for use with the JIT and one for other things, seems suboptimal.In my opinion having a general linker in the JIT is sub optimal. We should not be desiginig lld around an idea there is not even a consensus to. And even if it is case that having a general linker is the best way to write a JIT (I would love to know why a JIT needs something that handles copy relocations), we will not be able to evaluate the trade offs with the stand alone lld until we finished it. Cheers, Rafael
Hal Finkel via llvm-dev
2016-Dec-13 20:23 UTC
[llvm-dev] LLD status update and performance chart
----- Original Message -----> From: "Rafael Avila de Espindola" <rafael.espindola at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 2:13:49 PM > Subject: Re: [llvm-dev] LLD status update and performance chart > > Hal Finkel <hfinkel at anl.gov> writes: > > > >> Please tell me what you think about how reusable components would > >> be > >> like. Which parts of the linker can be reusable components? Is > >> that > >> really feasible? > > As far as I'm concerned, your response, "That said, I think the > > current our 'API' to allow users call our linker's main function > > hit the sweet spot. I know at least a few LLVM-based language > > developers who want to eliminate external dependencies and embed a > > linker to their compilers. That's a reasonable usage, and I think > > allowing them to pass a map from filename to MemoryBuffer objects > > makes sense, too. That would be done without affecting the overall > > linker architecture. I don't oppose to that idea, and if someone > > wrote a patch, I'm fine with that" is perfectly appropriate. We > > need to guide these discussions with use cases, and that's the use > > case that's been provided so far. > > > > Longer term, we also should take a serious look at how to unify the > > functionality in LLD with that in our JIT runtime linker. Having > > two linkers in the LLVM project, one for use with the JIT and one > > for other things, seems suboptimal. > > In my opinion having a general linker in the JIT is sub optimal. We > should not be desiginig lld around an idea there is not even a > consensusI think there is consensus on not wanting duplicate functionality between LLD and lib/ExecutionEngine. That does not mean that the JIT needs a general linker, but that whatever functionality is common is refactored in a such a way that separate implementations of the same functionality are not required. Now maybe the JIT's linking functionality should be so different from what LLD does that there's no overlap, but I think that a lot of assumed that there was significant overlap (at least as things currently stand). -Hal> to. And even if it is case that having a general linker is the best > way > to write a JIT (I would love to know why a JIT needs something that > handles copy relocations), we will not be able to evaluate the trade > offs with the stand alone lld until we finished it. > > Cheers, > Rafael >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
Rafael Avila de Espindola via llvm-dev
2016-Dec-13 20:50 UTC
[llvm-dev] LLD status update and performance chart
>> In my opinion having a general linker in the JIT is sub optimal. We >> should not be desiginig lld around an idea there is not even a >> consensus > > I think there is consensus on not wanting duplicate functionality > between LLD and lib/ExecutionEngine. That does not mean that the JIT > needs a general linker, but that whatever functionality is common is > refactored in a such a way that separate implementations of the same > functionality are not required.If it is possible, sure. Even if the JIT design is suboptimal, it would be nice if didn't involve coding their own .o relocation processing. The first time I implemented relocation processing in lld I actually had an eye at sharing the code. It was even in our internal project management bullet list and assigned to me by my request. As I learned as I implemented more and more of lld, the actual application of relocations is small part of the linker interaction. A big part is deciding about relaxations, copy relocations, gots and plts, so I rewrote the relocation handling in its current form (r266158). That involves saving information during the first of two passes over the relocations. I really don't think that that is what the JIT wants.> Now maybe the JIT's linking functionality should be so different from > what LLD does that there's no overlap, but I think that a lot of > assumed that there was significant overlap (at least as things > currently stand).That is exactly my impression, but I am only working on lld, not in the JIT, so it is hard to show it. The current design needs to apply regular .o relocations, which is unfortunate, but not much more of the linker. Don't let that or my previous failure block you. If you have a patch to share the relocation processing code that doesn't compromise lld, please send a patch. Cheers, Rafael