This is the mail archive of the gcc-bugs@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]

[Bug target/43814] gcc failed to inline memcpy


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-02 17:01:08 UTC ---
On Thu, 2 Dec 2010, mkuvyrkov at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
> 
> --- Comment #7 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> 2010-12-02 16:42:40 UTC ---
> (In reply to comment #6)
> ...
> < , as an example look at the types the C frontend
> > generates for struct X __attribute__((packed)) { int x; };
> > void foo (struct X *p, int  *q) { memcpy(&p->x, q, 4); } - &p->x
> > will have int * type, not int aligned(1) * type.
> ...
> > I considered infering initial alignment from function argument pointers
> > pointed-to types.  But I think that's still dangerous.  Also alignment
> > can be infered from dereferences, but that doesn't easily fit into the
> > CCP framework (there's no def for the pointer) and is also dangerous
> > as there is a lot of code out there that simply assumes misaligned
> > accesses are ok.
> > 
> > In short, it's not easy.  I'd consider the pointer argument thing
> > for 4.6,
> 
> Do I understand correctly that alignment of &p->x from the above example can be
> correctly inferred from argument 'p'?

No, not at the moment.

> > but would it really help in practice (as opposed to
> > simple artificial testcases)?
> 
> The above example was reduced from Dalvik VM, used in Android, and, generally,
> expanding __builtin_memcpy and company to 4-byte loads/stores instead of 1-byte
> loads/store is a problem worth fixing.
>
> From the front-end point of view, are there any inherit problems that prevent
> front-ends setting reliable alignment information on the types that middle-end
> could trust?  The information is there, right?  It's just that middle-end
> cannot trust it due to several unfortunate instances when front-end sets it
> wrong.

The frontend does not try to set alignment information on types used as
structure members, and those leak through address-taking.  That's the
main exisiting issue (there may be others, but that's the one I know).

We also have the issue that for example Ada uses VIEW_CONVERT_EXPRs
where I am not sure if they have correct alignment information on them.

In the end we _should_ be able to use alignment information of the
types used at the access (that's also more reliable as compared to
use alignment information from pointer argument types).

But we already do that in MEM_REF expansion:

        align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
                     get_object_alignment (exp, BIGGEST_ALIGNMENT));

Richard.


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