search for: desiginig

>> 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 i...

...o 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 fi...

...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 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...

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Rafael Avila de Espindola" <rafael.espindola at gmail.com>, > "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 12:56:41 PM > Subject: Re: [llvm-dev] LLD status update and