On Tue, 6 Oct 2020 at 11:38, Dave Martin <Dave.Martin@xxxxxxx> wrote: > > On Mon, Oct 05, 2020 at 02:24:47PM -0500, Jeremy Linton wrote: > > Hi, > > > > On 10/5/20 1:54 PM, Ard Biesheuvel wrote: > > >On Mon, 5 Oct 2020 at 20:18, Jeremy Linton <jeremy.linton@xxxxxxx> wrote: > > >> > > >>The AES code uses a 'br x7' as part of a function called by > > >>a macro, that ends up needing a BTI_J as a target. > > > > > >Could we instead just drop the tail call, i.e, replace it with a ret > > >and do a 'bl' after it returns? The indirect call does not really > > >serve a purpose here anyway > > > > Yes, that is an option, it adds an extra ret. Which probably doesn't mean > > much in most cases. I assumed this code was optimized this way because it > > mattered somewhere. > > Since this really does seem to be a tail-call and since x16 and x17 > appear to be otherwise unused here, can we not just use x16 or x17 > instead of x7? > > This relies on there being no other calls to veneered functions in the > mix, but this code is all in a single section so that shouldn't be a > concern. > > Due to the magic status of x16 and x17 in br instructions, the resulting > jump should be compatible with BTI c. I think this matches how the > compiler should typically compile tail-calls. > Ah, excellent point. That is definitely the cleanest fix.
