On Fri, Jun 05, 2015 at 12:55:04PM +0400, Mikhail Maltsev wrote:
> 05.06.2015 13:02, Ondřej Bílka writes:
> > Also as I mentioned bugs before gcc now doesn't handle alignment well so
> > it doesn't optimize following to zero for aligned code.
> >
> > align = ((uintptr_t) x) % 16;
> >
> That is b
On Fri, 5 Jun 2015, Mikhail Maltsev wrote:
> There are other issues with macros in glibc headers (well, not as
> significant as performance-related concerns, but never the less).
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24016#c3
>
> > #include
> > int foo(void *x) {
> > return strcm
Ondřej Bílka writes:
>
> On ivy bridge I got that Using rep stosq for memset(x,0,4096) is 20%
> slower than libcall for L1 cache resident data while 50% faster for data
> outside cache. How do you teach compiler that?
It would be in theory possible with autofdo. Profile with a cache miss
event. C
On Fri, Jun 05, 2015 at 09:26:33AM +0400, Mikhail Maltsev wrote:
> > The compiler has much more information than the headers.
> > - It can do alias analysis, so to avoid needing to handle overlap
> > and similar.
> > - It can (sometimes) determine alignment, which is important
> > information for t
05.06.2015 13:02, Ondřej Bílka writes:
> Also as I mentioned bugs before gcc now doesn't handle alignment well so
> it doesn't optimize following to zero for aligned code.
>
> align = ((uintptr_t) x) % 16;
>
That is because GCC is conservative and supports some non-ABI-compliant
memory allocator
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,
On Fri, Jun 05, 2015 at 11:02:03AM +0200, Ondřej Bílka wrote:
> On Thu, Jun 04, 2015 at 02:34:40PM -0700, Andi Kleen wrote:
> > The compiler has much more information than the headers.
> >
> > - It can do alias analysis, so to avoid needing to handle overlap
> > and similar.
>
> Could but it coul
On Thu, Jun 04, 2015 at 02:34:40PM -0700, Andi Kleen wrote:
> The compiler has much more information than the headers.
>
> - It can do alias analysis, so to avoid needing to handle overlap
> and similar.
Could but it could also export that information which would benefit
third parties.
> - It ca
05.06.2015 1:34, Andi Kleen writes:
> Ondřej Bílka writes:
>
>> As I commented on libc-alpha list that for string functions a header
>> expansion is better than builtins from maintainance perspective and also
>> that a header is lot easier to write and review than doing that in gcc
>> Jeff said t
Ondřej Bílka writes:
> As I commented on libc-alpha list that for string functions a header
> expansion is better than builtins from maintainance perspective and also
> that a header is lot easier to write and review than doing that in gcc
> Jeff said that it belongs to gcc. When I asked about be
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> On Thu, 4 Jun 2015, Ondřej Bílka wrote:
>
> > As I commented on libc-alpha list that for string functions a header
> > expansion is better than builtins from maintainance perspective and also
> > that a header is lot easier to write a
On 06/04/2015 06:33 AM, Jakub Jelinek wrote:
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
Again is this worth a gcc pass?
This isn't a matter of compiler passes; it's additional checks in existing
built-in function handling. Maybe that built-in function handling should
move t
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> > Again is this worth a gcc pass?
>
> This isn't a matter of compiler passes; it's additional checks in existing
> built-in function handling. Maybe that built-in function handling should
> move to the match-and-simplify infrastruc
On Thu, 4 Jun 2015, Ondřej Bílka wrote:
> As I commented on libc-alpha list that for string functions a header
> expansion is better than builtins from maintainance perspective and also
> that a header is lot easier to write and review than doing that in gcc
> Jeff said that it belongs to gcc. Whe
14 matches
Mail list logo
