[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

2018-01-29 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 Yann Collet changed: What|Removed |Added CC||yann.collet.73 at gmail dot com

[Bug c/82802] New: Potential UBSAN error with pointer difference (32-bits mode)

2017-11-01 Thread yann.collet.73 at gmail dot com
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann.collet.73 at gmail dot com Target Milestone: --- As part of our CI test suite, we compile and run fuzzer tests every day. The UBSAN test has been failing for some time now. I suspect

[Bug c/67435] Feature request: Implement align-loops attribute

2015-10-20 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #10 from Yann Collet --- > there already is an aligned attribute for functions, variables and fields, Sure, but none of them is related to aligning the start of an hot instruction loop. Aligning the function instead looks like a

[Bug c/67435] Large performance drop on apparently unrelated changes (potential cause : critical loop instruction alignment)

2015-09-03 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #8 from Yann Collet --- Thanks for the link. It's a very good read, and indeed, completely in line with my recent experience. Recommended solution seems to be the same : "-falign-loops=32" The article also mentions that the issue

[Bug c/67435] Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

2015-09-02 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #6 from Yann Collet --- The issue seems in fact related to _instruction alignment_. More precisely, to alignment of some critical loop. That's basically why adding some code in the file would just "pushes" some other code into

[Bug c/67435] New: Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

2015-09-02 Thread yann.collet.73 at gmail dot com
: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann.collet.73 at gmail dot com Target Milestone: --- Some weird effect with gcc (tested version : 4.8.4). I've got a performance oriented code

[Bug c/67435] Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

2015-09-02 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #5 from Yann Collet --- Complementary information : -Winline : does not output anything (is that normal ?) -fdump-ipa-inline : produce several large files, the interesting one being 1.5 MB long. That's a huge dump to analyze.

[Bug c/67435] Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

2015-09-02 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #4 from Yann Collet --- > Gcc also tries to limit code growth for the unit also which might be > something you are seeing. Yes, that could be the case. Is there some information available somewhere on such unit-level limit ?

[Bug c/67366] New: Poor assembly generation for unaligned memory accesses on ARM v6 v7 cpus

2015-08-26 Thread yann.collet.73 at gmail dot com
: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann.collet.73 at gmail dot com Target Milestone: --- Accessing unaligned memory positions used to be forbidden on ARM cpus. But since ARMv6 (quite many years by now

[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64

2015-08-12 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #18 from Yann Collet yann.collet.73 at gmail dot com --- This issue makes me wonder : how to efficiently access unaligned memory ? The case in point is ARM cpu. They don't support SSE/AVX, so they seem unaffected by this specific

[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64

2015-04-09 Thread yann.collet.73 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 Yann Collet yann.collet.73 at gmail dot com changed: What|Removed |Added CC||yann.collet