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
