On Mon, 10 Mar 2008, Alexandre Oliva wrote: > On Mar 9, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > On Sun, 9 Mar 2008, Alexandre Oliva wrote: > >> AM33/2.0 and H8SX come to mind, although it's been a while since I > >> dealt with the memory bit-field operations of these two ports to have > >> the details handy. > > > Ok, I would expect it a size benefit at most. > > I wouldn't think so. Turning a single hardware-optimized instruction > into a series of load, shift, mask, combine, store is unlikely to > benefit just size. Especially considering that these optimized > instructions were introduced in revisions of the processor. > > And then, I've failed to see a compelling reason to justify such a > change, that would have the effect of disabling this optimization, > even if it was "just" a size optimization. > > >> >> > Right. By means of fixing the BIT_FIELD_REF_UNSIGNED case it is now > >> >> > as specified above. > >> >> > >> >> This doesn't make the change that went in > > >> > ? > > >> ... desirable. > > > To recap, what went in is a restriction to constant args 2 and 3 and > > a result TYPE_PRECISION (in case of intergal type) or MODE_PRECISION > > (in other cases) matching to the bit-field size in argument 2. > > > The latter change made BIT_FIELD_REF_UNSIGNED redundant and (finally) > > allows for constant folding of BIT_FIELD_REF in fold_ternary. > > Good, then you didn't put in the requirement that the first argument > must be a gimple reg, and that its type must be the same as that of > the bit-field. Those are the changes I object to, but you said they > had gone in. I couldn't find the patch that did it, but I took your > word for it. I'm glad it was just a misunderstanding. > > As for removing BIT_FIELD_REF_UNSIGNED, I don't have much of a problem > with it. Using the unsignedness of the BIT_FIELD_REF type works > AFAICT. > > However, requiring a perfect match between the result type and the > extracted bit-width is troublesome, because we don't have > language-independent machinery to generate types with arbitrary widths > or even arbitrary precisions. > > > >> You make for much better optimization, at least with current > >> handling of BIT_FIELD_REF. > > >> OTOH, the much constrained version of BIT_FIELD_REF you propose will > >> indeed only generate lots of IL for the most common case of > >> BIT_FIELD_REF. > > > It generates much less IL than what the SRA lowering currently does. > > 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? > 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? It sounds easier to do from BIT_FIELD_REF and BIT_FIELD_EXPR on scalars. SRA _does_ pessimize code in some cases. BIT_FIELD_REF lowering will so as well - after all we are in target independent code. But yeah, it's way easier to add things here and there than to make some general changes and still keep people happy :( Richard.
