On Sat, 8 Mar 2008, Alexandre Oliva wrote: > On Mar 4, 2008, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > the type of the result is unspecified. > > ??? You mean, other than by TREE_TYPE of the BIT_FIELD_REF? I'm > pretty sure that's what specifies the type of the result.
You are late, the second patch installed that gets rid of BIT_FIELD_REF_UNSIGNED constrains it to be of the same "precision" of the extracted bitsize. > > I suggest to make sure that bit position and size are constants, > > +1 > > > the object referenced is of integral type > > This would break the use of SRA to extract sub-objects of non-integral > type. IIRC Ada does such things. No frontend generates BIT_FIELD_REF. But yes, SRA does with structures as base object. We don't yet enforce this, MEM_REF will enforce BIT_FIELD_REF operates on registers only. > > the result type is of the same type as the operand zero type > > Err, this doesn't make much sense to me. Consider: Right. By means of fixing the BIT_FIELD_REF_UNSIGNED case it is now as specified above. > It seems like what you're proposing would require explicit > VIEW_CONVERT_EXPRs from k to some integral type, then a BIT_FIELD_REF > that extracts bits into the same type, and then some other conversion > to the type with the width and precision of the field type. The least conversion is removed. You can look at the MEM_REF branch and see that the load from memory is done with a MEM_REF expression from the register result the bits are extracted with BIT_FIELD_REF. > This is not just a lot of explicit conversion that might very well be > encoded in BIT_FIELD_REF by avoiding its now-redundant TREE_TYPE (not > necessarily a bad thing), but also a requirement for significantly > different code paths to handle the two cases, which AFAICT will both > lead to poorer optimization. > > E.g., how do you envision generating code for foo() above? (The call > to bar() is there just to prevent the accesses to k from being > short-circuited, such that reads and writes are both clearly spelled > out). > > FWIW, what we (could) do now is something along the lines of: > > BIT_FIELD_REF(int)<k, 3, 0> = x; > BIT_FIELD_REF(unsigned)<k, 5, 3> = y; > bar(); > T.1 = BIT_FIELD_REF(int)<k, 3, 0>; > T.2 = BIT_FIELD_REF(unsigned)<k, 5, 3>; > T.3 = (int)T.2; > T.4 = T.1 + T.3; > return T.4; > > > (and not a bitfield type of the referenced size -- in which case the > > BIT_FIELD_REF_UNSIGNED would be useless) > > There's no such thing as a language-independent bitfield type of the > referenced size. When you ask for an integral type with a certain bit > width, you may get a wider type, even with a wider precision. And > that's where BIT_FIELD_REF_UNSIGNED should come into play, although I > remember I had to deal with some inconsistencies in the handling of > this stuff while working on SRA. > > > fold currently optimizes a.b.c == 0 to BIT_FIELD_REF <a, 8, big-num> & 1 > > for bit field field-decls c. IMHO this is bad because it pessimizes > > TBAA (needs to use a's alias set, not the underlying integral type > > alias set) and it "breaks" type correctness as arbitrary structure > > types appear as operand zero. > > I don't quite see how this breaks type correctness, can you elaborate? > > I understand the problem about alias sets. Ideally, if we're > accessing part of an object with BIT_FIELD_REF, it would be useful to > narrow the alias set such that only the alias sets of the fields > present in words related with that region get a say in the aliasing > properties of this statement. For BIT_FIELD_REFs used only as inputs, With MEM_REF this is done by explicitly tracking the alias-set used for the access in the MEM_REF expr. Richard.
