Hi, >> Ultimately, the best solution here will probably depend on which we >> think is more likely, copysign or the example I give above. > I'd tend to suspect we'd see more pure integer bit twiddling than the > copysign stuff.
All we need to do is to clearly separate the integer and FP/SIMD cases. Copysign should always expand into a pattern that cannot generate integer instructions. This could be done by adding a bit/bif pattern with UNSPEC for the DI/SImode case or use V2DI/V2SI in the copysign expansion. > Could we have the bfxil pattern have an alternative that accepts vector > regs and generates bit in appropriate circumstances? We already do that in too many cases, and it only makes the problem worse since the register allocator cannot cost these patterns at all (let alone accurately). This is particularly bad when the expansions are wildly different and emit extra instructions which cannot be optimized after register allocation. We simply need to make an early choice which register file to use. > Hmm, maybe the other way around would be better. Have the "bit" > pattern with a general register alternative that generates bfxil when > presented with general registers. We already have that, and that's a very complex pattern which already results in inefficient integer code. For the overlapping cases between bfi and bfxil the mid-end should really simplify one into the other to avoid having to have multiple MD patterns for equivalent expressions. This may solve the problem. > I would generally warn against hiding things in unspecs like you've > suggested above. We're seeing cases where that's been on in the x86 > backend and it's inhibiting optimizations in various places. In the general case we can't describe a clear preference for a specific register file without support for scalar vector types (eg. V1DI, V1SI) or having a way to set virtual register preferences at expand time. Wilco
