This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Constrain valid arguments to BIT_FIELD_REF
On Sat, 8 Mar 2008, Alexandre Oliva wrote:
> On Mar 4, 2008, Richard Guenther <rguenther@suse.de> 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.