Re: Deduplicate io_*_prep calls?

[Jens Axboe <axboe@kernel.dk>]

On 2/24/20 9:53 AM, Andres Freund wrote:
> Hi,
> 
> On 2020-02-24 08:40:16 -0700, Jens Axboe wrote:
>> Agree that the first patch looks fine, though I don't quite see why
>> you want to pass in opcode as a separate argument as it's always
>> req->opcode. Seeing it separate makes me a bit nervous, thinking that
>> someone is reading it again from the sqe, or maybe not passing in
>> the right opcode for the given request. So that seems fragile and it
>> should go away.
> 
> Without extracting it into an argument the compiler can't know that
> io_kiocb->opcode doesn't change between the two switches - and therefore
> is unable to merge the switches.
> 
> To my knowledge there's no easy and general way to avoid that in C,
> unfortunately. const pointers etc aren't generally a workaround, even
> they were applicable here - due to the potential for other pointers
> existing, the compiler can't assume values don't change.  With
> sufficient annotations of pointers with restrict, pure, etc. one can get
> it there sometimes.
> 
> Another possibility is having a const copy of the struct on the stack,
> because then the compiler often is able to deduce that the value
> changing would be undefined behaviour.
> 
> 
> I'm not sure that means it's worth going for the separate argument - I
> was doing that mostly to address your concern about the duplicated
> switch cost.

Yeah I get that, but I don't think that's worth the pain. An alternative
solution might be to make the prep an indirect call, and just pair it
with some variant of INDIRECT_CALL(). This would be trivial, as the
arguments should be the same, and each call site knows exactly what
the function should be.

-- 
Jens Axboe