This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Incorrect bitfield aliasing with Tree SSA


On 6/15/07, Adam Nemet <anemet@caviumnetworks.com> wrote:
Daniel Berlin writes:
> On 6/15/07, Adam Nemet <anemet@caviumnetworks.com> wrote:
> > get_alias_set and internally record_component_aliases makes
> > assumptions about the IR that are only valid in RTL.
>
> What is this assumption, exactly?

That non-addressable fields are always accessed through alias set 0.
For example:

  X: (set (mem A) ...)
  Y: (set (zero_extract (mem B) 2 2) ...)

Let's say that A and B both point to the same type and have the same
alias set 1.  The bitfield store in Y would normally have the alias
set of the field, let's say 2.  Normally 2 would have to be recorded
as an alias subset of 1.  This is not done in RTL and the comment
before record_component_aliases mentions this:

/* Record that component types of TYPE, if any, are part of that type for
   aliasing purposes.  For record types, we only record component types
   for fields that are marked addressable.

HMm, i'd just record it for all of them, since the are accessible through a pointer to the structure. Just because you can't directly take the address of a bitfield doesn't mean you can't access one through a pointer, which is the entire purpose of knowing alias sets (knowing what a pointer dereference could affect).

This should solve the problem without having to do anything IR specific.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]