This is the mail archive of the 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: Builtin expansion versus headers optimization: Reductions

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?

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