Simon Atanasyan via llvm-dev
2017-Jan-18 23:59 UTC
[llvm-dev] RFC: LLD range extension thunks
On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: On 4 January 2017 at 13:34, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I'm about to start working on range extension thunks in lld. This is > an attempt to summarize the approach I'd like to take and what the > impact will be on lld outside of thunks.Now that LLD works well for FreeBSD/amd64 (and arm64 is very close) I'm looking at other architectures, starting with mips64. The statically-linked toolchain components currently fail to link with an out of range jump, so I'm very interested in seeing this work progress. Are you looking at only arm and AArch64? Once the infrastructure is in I'll try to take a look at mips if nobody else does first. I'm waiting for this changes too. Now mips thunks places at the end of the corresponding section. Not sure about FreeBSD but on Linux that leads to incorrect code in case of static linking -- a thunk goes between crt*.o files which needs to be "joined" together. Gnu linker puts thunks to the separate section. We need to do the same thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170119/e4447c5d/attachment.html>
Saleem Abdulrasool via llvm-dev
2017-Jan-19 03:00 UTC
[llvm-dev] RFC: LLD range extension thunks
Out of curiosity, would this be done in a object format agnostic way? Windows ARM requires the same branch island support, and the logic for the detection and placement could be shared across ELF and COFF I suspect. On Wed, Jan 18, 2017 at 3:59 PM, Simon Atanasyan via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: > > On 4 January 2017 at 13:34, Peter Smith via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm about to start working on range extension thunks in lld. This is > > an attempt to summarize the approach I'd like to take and what the > > impact will be on lld outside of thunks. > > Now that LLD works well for FreeBSD/amd64 (and arm64 is very close) > I'm looking at other architectures, starting with mips64. The > statically-linked toolchain components currently fail to link with an > out of range jump, so I'm very interested in seeing this work > progress. Are you looking at only arm and AArch64? Once the > infrastructure is in I'll try to take a look at mips if nobody else > does first. > > > I'm waiting for this changes too. Now mips thunks places at the end of the > corresponding section. Not sure about FreeBSD but on Linux that leads to > incorrect code in case of static linking -- a thunk goes between crt*.o > files which needs to be "joined" together. Gnu linker puts thunks to the > separate section. We need to do the same thing. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170118/667507e9/attachment.html>
On Wed, Jan 18, 2017 at 7:00 PM, Saleem Abdulrasool via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Out of curiosity, would this be done in a object format agnostic way? > Windows ARM requires the same branch island support, and the logic for the > detection and placement could be shared across ELF and COFF I suspect. >I think that most of the code changes needed for this are going to be just refactoring to "put a loop around the Writer" and so is inherently specific to ELF and COFF (since they have different Writer's). Initial thunk placement heuristics/algorithms etc. are likely to be pretty simple (i.e. too small lines of code to really share meaningfully). If we start doing something really complicated for placing thunks it may make sense to factor out so it can be shared, but it may end up like ICF where the algorithms we use are the same, but the details of the data structures and semantics differ enough that it's not clear if sharing them would be a net savings or not. -- Sean Silva> > On Wed, Jan 18, 2017 at 3:59 PM, Simon Atanasyan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: >> >> On 4 January 2017 at 13:34, Peter Smith via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > I'm about to start working on range extension thunks in lld. This is >> > an attempt to summarize the approach I'd like to take and what the >> > impact will be on lld outside of thunks. >> >> Now that LLD works well for FreeBSD/amd64 (and arm64 is very close) >> I'm looking at other architectures, starting with mips64. The >> statically-linked toolchain components currently fail to link with an >> out of range jump, so I'm very interested in seeing this work >> progress. Are you looking at only arm and AArch64? Once the >> infrastructure is in I'll try to take a look at mips if nobody else >> does first. >> >> >> I'm waiting for this changes too. Now mips thunks places at the end of >> the corresponding section. Not sure about FreeBSD but on Linux that leads >> to incorrect code in case of static linking -- a thunk goes between crt*.o >> files which needs to be "joined" together. Gnu linker puts thunks to the >> separate section. We need to do the same thing. >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170118/2634ce4c/attachment-0001.html>
I think anything that we come up with will need to support Mips as well as ARM and AArch64. I'm aware of the Mips LA25 Thunk and the need for these Thunks to be placed before the Target Section. I'm intending that the first patch that uses synthetic sections for Thunks will do this. I'm not intending to go looking for new Mips Thunk types to implement, I think it would be better that someone with more experience of Mips and an ability to test properly, implemented these [*]. I'm similarly ignorant of Power, which has limited range branch instructions. My plan for implementation so far is to convert the existing implementation to use synthetic sections without trying to do range extension. When that is in and working we can build upon that to include range extension. If we can make the range detection and thunk placement sufficiently flexible it shouldn't be difficult to add new Thunks later. [*] I can see that the pseudo-direct addressing used by J and JAL instructions could in principle have range extension thunks and would need different handling to ARM/AArch64 branches with PC-relative offsets. I'm not sure whether Mips toolchains typically do use Thunks in this case or if it is the caller's responsibility to use an indirect jump via JR instead. On 18 January 2017 at 23:59, Simon Atanasyan <simon at atanasyan.com> wrote:> > > On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: > > On 4 January 2017 at 13:34, Peter Smith via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I'm about to start working on range extension thunks in lld. This is >> an attempt to summarize the approach I'd like to take and what the >> impact will be on lld outside of thunks. > > Now that LLD works well for FreeBSD/amd64 (and arm64 is very close) > I'm looking at other architectures, starting with mips64. The > statically-linked toolchain components currently fail to link with an > out of range jump, so I'm very interested in seeing this work > progress. Are you looking at only arm and AArch64? Once the > infrastructure is in I'll try to take a look at mips if nobody else > does first. > > > I'm waiting for this changes too. Now mips thunks places at the end of the > corresponding section. Not sure about FreeBSD but on Linux that leads to > incorrect code in case of static linking -- a thunk goes between crt*.o > files which needs to be "joined" together. Gnu linker puts thunks to the > separate section. We need to do the same thing.
Are you looking only at fixed length ISAs and adding thunks, or also at ISAs with different size branch instructions with different ranges, and relaxing short branches to either longer branches (if that will reach) or to thunks (if not)? Note that it's not purely "thunks for RISC" and "longer instructions for CISC". There are ISAs that could use a mixture of techniques. For example, Thumb2 has 16 bit branch instructions with a range of -252 - +256, and 32 bit branch instructions with a range of +/-16MB. If neither of those will work then you use a short or long branch to a thunk. Another example is RISC-V, which has: - 16 bit conditional branch instructions with +/-256 bytes range - 16 bit unconditional branch(&link) instructions with +/-2KB range - 32 bit conditional branch instructions with +/-2KB range - 32 bit unconditional branch(&link) instructions with +/-1MB range - 32 bit unconditional branch(&link) to reg +/-2KB offset that can be paired with a LUI or AUIPC (which load or add a 20 bit immediate shifted left by 12) to make a two instruction sequence that can do an absolute 32 bit branch or relative branch to PC +/ 2 GB. So thunks are never needed, but code size can change. If you're optimizing for size then it could be an advantage to use a thunk anyway, if it can be shared. The current clang & gcc versions always generate the full two instruction sequence, and then the linker deletes the LUI or AUIPC if the literal is zero. This does not produce as optimal code as starting with short branches and expanding the ones that won't reach. Both ARM and RISC-V ABIs have defined scratch registers that the linker (or other) can freely clobber for calculations inside thunks, or when converting instructions to multi-instruction sequences. On Thu, Jan 19, 2017 at 1:33 PM, Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I think anything that we come up with will need to support Mips as > well as ARM and AArch64. I'm aware of the Mips LA25 Thunk and the need > for these Thunks to be placed before the Target Section. I'm intending > that the first patch that uses synthetic sections for Thunks will do > this. I'm not intending to go looking for new Mips Thunk types to > implement, I think it would be better that someone with more > experience of Mips and an ability to test properly, implemented these > [*]. I'm similarly ignorant of Power, which has limited range branch > instructions. > > My plan for implementation so far is to convert the existing > implementation to use synthetic sections without trying to do range > extension. When that is in and working we can build upon that to > include range extension. If we can make the range detection and thunk > placement sufficiently flexible it shouldn't be difficult to add new > Thunks later. > > [*] I can see that the pseudo-direct addressing used by J and JAL > instructions could in principle have range extension thunks and would > need different handling to ARM/AArch64 branches with PC-relative > offsets. I'm not sure whether Mips toolchains typically do use Thunks > in this case or if it is the caller's responsibility to use an > indirect jump via JR instead. > > > On 18 January 2017 at 23:59, Simon Atanasyan <simon at atanasyan.com> wrote: > > > > > > On Jan 19, 2017 2:48 AM, "Ed Maste" <emaste at freebsd.org> wrote: > > > > On 4 January 2017 at 13:34, Peter Smith via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> I'm about to start working on range extension thunks in lld. This is > >> an attempt to summarize the approach I'd like to take and what the > >> impact will be on lld outside of thunks. > > > > Now that LLD works well for FreeBSD/amd64 (and arm64 is very close) > > I'm looking at other architectures, starting with mips64. The > > statically-linked toolchain components currently fail to link with an > > out of range jump, so I'm very interested in seeing this work > > progress. Are you looking at only arm and AArch64? Once the > > infrastructure is in I'll try to take a look at mips if nobody else > > does first. > > > > > > I'm waiting for this changes too. Now mips thunks places at the end of > the > > corresponding section. Not sure about FreeBSD but on Linux that leads to > > incorrect code in case of static linking -- a thunk goes between crt*.o > > files which needs to be "joined" together. Gnu linker puts thunks to the > > separate section. We need to do the same thing. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170119/12c0fdc9/attachment.html>