This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Builtin expansion versus headers optimization: Reductions
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, gcc at gcc dot gnu dot org, law at redhat dot org, libc-alpha at sourceware dot org
- Date: Fri, 5 Jun 2015 11:52:48 +0200
- Subject: Re: Builtin expansion versus headers optimization: Reductions
- Authentication-results: sourceware.org; auth=none
- References: <20150604105929 dot GA19141 at domone> <87fv67nonj dot fsf at tassilo dot jf dot intel dot com> <20150605090203 dot GA16032 at domone> <20150605092312 dot GP10247 at tucnak dot redhat dot com>
On Fri, Jun 05, 2015 at 11:23:12AM +0200, Jakub Jelinek wrote:
>
> That is simply not true. E.g.
> struct __attribute__((aligned (16))) S { char b[16]; };
> struct S a;
>
> unsigned long
> foo (void)
> {
> return (((unsigned long) &a) % 16);
> }
> is optimized into 0, many other testcases too, the CCP pass takes alignment
> info into account and optimize based on that. If you are talking about
> result of malloc, supposedly it is because glibc headers don't properly mark
> malloc with the alloc_align attribute yet.
>
Ok, I take that back. I just didn't heard that we should use that
attribute. I though that __attribute__ ((__malloc__)) implies that.
> > > - With profile feedback it can use value histograms to determine the
> > > best code.
> > >
> > Problem is that histograms are not enough as I mentioned before. For
> > profiling you need to measure useful data which differs per function and
> > should be done in userspace.
>
> For some builtin functions PGO can collect custom extra data, that the
> compiler then can use to decide how to expand the builtins.
> E.g. for some string op builtins PGO already collects average alignment and
> average size.
>
Where should I look?