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. 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. Unless you plan on extending the infrastructure that simplifies masks and shifts such that it deals with BIT_FIELD_REFs and lowers them, at least when operand 0 is a gimple reg, I'd strongly suggest you to leave the lowering in BIT_FIELD_REFs in SRA, or perhaps even do that as part of gimplification. > This all works fine with the lowering MEM_REF does. With less IL > than SRA creates (because of BIT_FIELD_REF). As long as it doesn't pessimize code (which is what the more IL was about), I'm game. >> BIT_FIELD_EXPR appears to be necessary only for SSA gimple registers. >> For addressable objects, a BIT_FIELD_REF lhs can be much simpler, and >> it may even generate better code without as much effort. > BIT_FIELD_REF doesn't play well with our scalar optimizers. Exactly. That's why I suggest BIT_FIELD_REFs only for addressable objects. SRA will scalarize them if it can; if it can't, scalar optimizers won't have much to do about them anyway. > You can't work on registers, as partial writes break SSA form, so > you need to keep a temporary in memory which is bad. And then, since this is only useful for gimple registers, and you get better code if you open-code the bit-field operations for them, I stand by my claim that it's pointless, and BIT_FIELD_REFs lowered into open-coded shifting and masking during gimplification would get us better code. -- 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}
