On Mar 10, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Mon, 10 Mar 2008, Alexandre Oliva wrote: >> The reason SRA generates more IL is *precisely* to get better >> optimization. The back-ends don't handle BIT_FIELD_REFs very well.
> So I thought they can do bit-field stores...? no? Err... Sorry, I didn't mean back-ends, I meant middle-end optimization passes. Dunno how I managed to mangle one into the other. >> There's a lot of code all over the compiler to simplify masking and >> shifting that, when you use BIT_FIELD_REF, doesn't (and can't) >> trigger. BIT_FIELD_REF hides masks and shifts, such that the compiler >> can't simplify them without lowering them in the first place. And the >> lowering is profitable. > So, how do you recover from shifting and masking to single instruction > bit-field stores? You don't. You don't open code these operations when they apply to memory. When they apply to gimple regs AKA pseudos, then you do, and then various back-ends have combine patterns to recover the relevant operations. > It sounds easier to do from BIT_FIELD_REF and BIT_FIELD_EXPR on > scalars. It is easier, indeed, but it will take a lot of work to get the same amount of optimization that we currently get, and, in order to perform *some* simplifications, you have to either open-code them, or extend BIT_FIELD_EXPR so as to specify a bit range to extract from the input and *another* bit range to replace. Such that you can combine say: T.1_0 = BIT_FIELD_REF <x, 5, 3>; y_2 = BIT_FIELD_EXPR <y_1, T.1_0, 12, 3>; into y_2 = BIT_FIELD_REPLACE <3, y_1, 12, x, 5>; With something like this you can eliminate unnecessary duplicate shifting from x to y, which is one of the various optimizations that the middle end can perform. OTOH, such shift redundancy elimination is unnecessary if a back-end offers efficient extv, extzv and insv patterns. But BIT_FIELD_REPLACE could expand to an extv/insv sequence or an extzv/insv sequence (signedness doesn't matter, since we're talking about the same number of bits in both cases), and, if such operations aren't available, in can be expanded as two masks, a single shift, and an or, rather than three masks and two shifts, which is what the two-gimple-stmt above would require. Note that BIT_FIELD_REPLACE supersedes both BIT_FIELD_REF and BIT_FIELD_EXPR, except for the lvalue meaning of BIT_FIELD_REF: BIT_FIELD_REF <A, B, C> could be expressed as say BIT_FIELD_REPLACE <C, 0, 0, A, B> and BIT_FIELD_EXPR <D, E, F, G> could be expressed as say BIT_FIELD_REPLACE <G, D, F, E, 0> And then, if we were to add another operand for the output, or express it as an assignment that could have one of the inputs as output, we'd have complete semantics, and then it would be "just" a matter of teaching all of the optimization passes that track bits and shifts to deal with BIT_FIELD_REPLACE. This would be just as needed for BIT_FIELD_REF and BIT_FIELD_EXPR anyway, but the fact that this hasn't been done for BIT_FIELD_REF yet makes me think I shouldn't hold my breath. > SRA _does_ pessimize code in some cases. BIT_FIELD_REF lowering > will so as well - after all we are in target independent code. How could it pessimize code? BIT_FIELD_REF is just an inflexible shorthand for the operations that end up taking place anyway. And the fact that it's inflexible does harm some optimizations that can be performed with open coding, and that are recognized and performed as a combined operation if no optimizations apply. I get a feeling that you're barking up the wrong tree here, but I can't claim to have compared in detail every single instance of generated code using BIT_FIELD_REF or open-coding it. > But yeah, it's way easier to add things here and there than to > make some general changes and still keep people happy :( Yeah, I can agree that making the changes in SRA only wasn't exactly the best approach. When I started, I had no idea that open coding was so necessary, and when I realized it, I had already spent way too much time on that particular issue, and I didn't get a feeling that I'd get buy-in for a larger revamp. Now, since there is a revamp underway, we might as well do it right, rather than introduce regressions just to keep things more uniform. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
