Re: DWZ 0.14 released

Btw, question for gcc/binutils Any reason the work done by tools like dwz couldn't be done in the compiler or linker? Seems a bit odd to have a post-linker that optimizes the generated code, when optimizations should already be enabled. Best regards Allan On Montag, 8. März 2021 13:43:11 CET

Re: [RFC] Increase libstdc++ line length to 100(?) columns

On Montag, 30. November 2020 16:47:08 CET Michael Matz wrote: > Hello, > > On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote: > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > > * Allan Sandfeld Jensen: > > > > If you _do_ change it. I wou

Re: [RFC] Increase libstdc++ line length to 100(?) columns

On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > * Allan Sandfeld Jensen: > > If you _do_ change it. I would suggest changing it to 120, which is next > > common step for a lot of C++ projects. > > 120 can be problematic for a full HD screen in portrait mod

Re: [RFC] Increase libstdc++ line length to 100(?) columns

On Freitag, 27. November 2020 00:50:57 CET Jonathan Wakely via Gcc wrote: > I've touched on the subject a few times, e.g. > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html > and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html > > Libstdc++ code is indented by 2 columns for

Re: RFC: -fno-share-inlines

On Montag, 24. August 2020 08:52:04 CEST Richard Biener wrote: > On Mon, Aug 10, 2020 at 9:36 AM Allan Sandfeld Jensen > > wrote: > > Following the previous discussion, this is a proposal for a patch that > > adds > > the flag -fno-share-inlines that can be u

Re: Peephole optimisation: isWhitespace()

On Freitag, 14. August 2020 18:43:12 CEST Stefan Kanthak wrote: > Hi @ll, > > in his ACM queue article , > Matt Godbolt used the function > > | bool isWhitespace(char c) > | { > | > | return c == ' ' > | > | || c == '\r' > | || c

RFC: -fno-share-inlines

Following the previous discussion, this is a proposal for a patch that adds the flag -fno-share-inlines that can be used when compiling singular source files with a different set of flags than the rest of the project. It basically turns off comdat for inline functions, as if you compiled

Re: Non-inlined functions and mixed architectures

On Dienstag, 4. August 2020 19:44:57 CEST Florian Weimer wrote: > * Allan Sandfeld Jensen: > > On Montag, 27. Juli 2020 10:54:02 CEST Florian Weimer wrote: > >> * Allan Sandfeld Jensen: > >> > On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: &

Re: Non-inlined functions and mixed architectures

On Montag, 27. Juli 2020 10:54:02 CEST Florian Weimer wrote: > * Allan Sandfeld Jensen: > > On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: > >> * Allan Sandfeld Jensen: > >> > A problem that I keep running into is functions defined headers, but >

Re: Non-inlined functions and mixed architectures

On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: > * Allan Sandfeld Jensen: > > A problem that I keep running into is functions defined headers, but used > > in sources files that are compiled with different CPU feature flags (for > > runtime CPU feature selecti

Non-inlined functions and mixed architectures

A problem that I keep running into is functions defined headers, but used in sources files that are compiled with different CPU feature flags (for runtime CPU feature selection). We know to make sure the functions are inlinable and their address never taken, but of course in debug builds they

Re: New x86-64 micro-architecture levels

On Freitag, 10. Juli 2020 19:30:09 CEST Florian Weimer via Gcc wrote: > glibc (or an alternative loader implementation) would search for > libraries starting at level D, going back to level A, and finally the > baseline implementation in the default library location. > > I expect that some

Re: issue with behavior change of gcc -r between gcc-8 and gcc-9

On Wednesday, 1 April 2020 19:48:11 CEST Olivier Hainque wrote: > > -r 's business was to arrange for the linker not to > complain because the closure is incomplete, leaving us > with complete control of the closure. > > It doesn't seem to me there was a really strong motivation > to suddenly

Re: Warning on move and dereference of unique_ptr in the same expression

On Montag, 3. Februar 2020 21:47:13 CET Marek Polacek wrote: > On Mon, Feb 03, 2020 at 09:26:40PM +0100, Allan Sandfeld Jensen wrote: > > Hello gcc > > > > I have now twice hit obscure bugs in Chromium that crashed on some > > compilers but not on others, and didn't

Warning on move and dereference of unique_ptr in the same expression

Hello gcc I have now twice hit obscure bugs in Chromium that crashed on some compilers but not on others, and didn't produce any warnings on any compiler. I would like to know if this code is as undefined as I think it is, and if it would make sense to have gcc warn about it. Both cases

Re: GCC Multi-Threading Ideas

On Freitag, 24. Januar 2020 17:29:06 CET Nicholas Krause wrote: > On 1/24/20 3:18 AM, Allan Sandfeld Jensen wrote: > > On Freitag, 24. Januar 2020 04:38:48 CET Nicholas Krause wrote: > >> On 1/23/20 12:19 PM, Nicholas Krause wrote: > >>> On 1/23/20 3:39 A

Re: GCC Multi-Threading Ideas

On Freitag, 24. Januar 2020 04:38:48 CET Nicholas Krause wrote: > On 1/23/20 12:19 PM, Nicholas Krause wrote: > > On 1/23/20 3:39 AM, Allan Sandfeld Jensen wrote: > >> On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote: > >>> Greetings All, > >>

Re: GCC Multi-Threading Ideas

On Montag, 20. Januar 2020 20:26:46 CET Nicholas Krause wrote: > Greetings All, > > Unfortunately due to me being rather busy with school and other things I > will not be able to post my article to the wiki for awhile. However > there is a rough draft here: >

Re: C2X Proposal, merge '.' and '->' C operators

On Monday, 16 December 2019 14:51:38 CET J Decker wrote: > Here's the gist of what I would propose... > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da > > In C, there are two operators . and -> used to access members of struct and > union types. These operators are specified such

Re: [PATCH] Come up with -flto=auto option.

On Mittwoch, 24. Juli 2019 08:45:21 CEST Martin Liška wrote: > On 7/24/19 12:11 AM, Allan Sandfeld Jensen wrote: > > On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: > >> Hi. > >> > >> As we as openSUSE started using -flto, I see it ver

Re: [PATCH] Come up with -flto=auto option.

On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: > Hi. > > As we as openSUSE started using -flto, I see it very handy to have > an option value that will automatically detect number of cores > that can be used for parallel LTRANS phase. > > Thoughts? > That's really nice. How much

Re: On -march=x86-64

On Donnerstag, 11. Juli 2019 20:58:04 CEST Allan Sandfeld Jensen wrote: > Years ago I discovered Chrome was optimizing with -march=x86-64, and > knowing was an undocumented arch that would optimize for K8 I laughed at it > and just removed that piece of idiocy from our fork of Chr

[Patch] Make x86-64 a generic architecture as documented

/gcc/ChangeLog @@ -1,3 +1,8 @@ +2019-07-13 Allan Sandfeld Jensen + + * gcc/common/config/i386/i386-common.c (processor_alias_table): Change + x86-64 architecture to use generic tuning and scheduling instead of K8. + 2019-07-11 Jakub Jelinek PR target/91124 diff --git a/gcc

On -march=x86-64

Years ago I discovered Chrome was optimizing with -march=x86-64, and knowing was an undocumented arch that would optimize for K8 I laughed at it and just removed that piece of idiocy from our fork of Chromium, so it would be faster than upstream. Recently though I noticed phoronix is also

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Freitag, 22. März 2019 14:38:10 CET Andrew Haley wrote: > On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote: > > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: > >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: > >>> From having fixed UBSAN warnings

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote: > On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote: > > From having fixed UBSAN warnings, I have seen many cases where undefined > > behavior was performed, but where the code was aware of it and the final > > res

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Donnerstag, 21. März 2019 23:31:48 CET Jakub Jelinek wrote: > On Thu, Mar 21, 2019 at 11:19:54PM +0100, Allan Sandfeld Jensen wrote: > > Hmm, I am curious. How strongly would gcc assume x is 0? > > If x is not 0, then it is undefined behavior and anything can happen, > so ye

Re: GCC turns &~ into | due to undefined bit-shift without warning

On Montag, 11. März 2019 10:14:49 CET Jakub Jelinek wrote: > On Mon, Mar 11, 2019 at 08:49:30AM +, Moritz Strübe wrote: > > Considering that C11 6.5.7#3 ("If the value of the right operand > > is negative or is greater than or equal to the width of the promoted > > left operand, the

Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)

On Freitag, 25. Januar 2019 07:22:36 CET Nikhil Benesch wrote: > Does anyone have advice to offer? Has anyone tried convincing the build > system to compile some of the other target libraries (like libstdc++ or > libgfortran) with -flto? > Make sure the static versions of the libraries are

Re: [Patch][GCC] Document and fix -r (partial linking)

On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote: > On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote: > > Patch updated. I specifically edited a number of the existing tests that > > used both -r and -nostdlib and removed -nostdlib so the patch is > > exerci

Re: [Patch][GCC] Document and fix -r (partial linking)

On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote: > On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote: > > Patch updated. I specifically edited a number of the existing tests that > > used both -r and -nostdlib and removed -nostdlib so the patch is > > exerci

Re: [Patch][GCC] Document and fix -r (partial linking)

tstrapped, I didn't notice any relevant failures when running the test suite (though I could have missed something, I am never comfortable reading that output). 'Allan >From 07ed41a9afd107c5d45feb1ead7a74ca735a1bb2 Mon Sep 17 00:00:00 2001 From: Allan Sandfeld Jensen Date: Sun, 26 Aug 2018 2

Re: [Patch][GCC] Document and fix -r (partial linking)

On Dienstag, 21. August 2018 00:38:58 CEST Joseph Myers wrote: > On Fri, 3 Aug 2018, Allan Sandfeld Jensen wrote: > > > I think you're changing the wrong place for this. If you want -r to be > > > usable with GCC without using -nostdlib (which is an interesting > > >

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Samstag, 11. August 2018 11:18:39 CEST Jakub Jelinek wrote: > On Sat, Aug 11, 2018 at 10:59:26AM +0200, Allan Sandfeld Jensen wrote: > > +/* A subroutine of ix86_expand_vec_perm_builtin_1. Try to implement D > > + using movss or movsd. */ > > +static bool > > +e

Re: [PATCH][x86] Match movss and movsd "blend" instructions

Updated: Match movss and movsd "blend" instructions Adds the ability to match movss and movsd as blend patterns, implemented in a new method to be able to match these before shuffles, while keeping other blends after. 2018-08-11 Allan Sandfeld Jensen gcc/config/i386

Re: [Patch][GCC] Document and fix -r (partial linking)

On Freitag, 3. August 2018 13:56:12 CEST Allan Sandfeld Jensen wrote: > On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote: > > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > > gcc/ > > > > > > * gcc.c: Correct default specs for -r >

Re: [Patch][GCC] Document and fix -r (partial linking)

On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > gcc/ > > > > * gcc.c: Correct default specs for -r > > I don't follow why your changes (which would need describing for each > individual

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Donnerstag, 2. August 2018 23:15:28 CEST Marc Glisse wrote: > On Thu, 2 Aug 2018, Allan Sandfeld Jensen wrote: > > I forgot. One of the things that makes using __builtin_shuffle ugly is > > that > > __v4si as the suffle argument needs to be in _mm_move_ss, is declar

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Donnerstag, 2. August 2018 23:46:37 CEST Jakub Jelinek wrote: > On Thu, Aug 02, 2018 at 10:50:58PM +0200, Allan Sandfeld Jensen wrote: > > Here is the version with __builtin_shuffle. It might be more expectable > > -O0, but it is also uglier. > > I don't find anythi

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Donnerstag, 2. August 2018 11:18:41 CEST Richard Biener wrote: > On Thu, Aug 2, 2018 at 11:12 AM Allan Sandfeld Jensen > > wrote: > > On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote: > > > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > >

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, > > > > __artificial__)) > > > > _mm_move_sd (__m128d __A, __m12

Re: [PATCH][x86] Match movss and movsd "blend" instructions

On Mittwoch, 1. August 2018 18:51:41 CEST Marc Glisse wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > extern __inline __m128d __attribute__((__gnu_inline__, __always_inline__, > > > > __artificial__)) > > > > _mm_move_sd (__m128d __A, __m12

Re: [Patch][GCC] Document and fix -r (partial linking)

On Mittwoch, 1. August 2018 18:32:30 CEST Joseph Myers wrote: > On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote: > > gcc/ > > > > * gcc.c: Correct default specs for -r > > I don't follow why your changes (which would need describing for each > individual

[Patch][GCC] Document and fix -r (partial linking)

The option has existed and been working for years, make sure it implies the right extra options, and list it in the documentation. 2018-08-01 Allan Sandfeld Jensen gcc/doc * invoke.texi: Document -r gcc/ * gcc.c: Correct default specs for -r --- gcc/doc/invoke.texi | 7 ++- gcc

[PATCH][x86] Match movss and movsd "blend" instructions

Adds the ability to match movss and movsd as blend patterns, implemented in a new method to be able to match these before shuffles, while keeping other blends after. 2018-07-29 Allan Sandfeld Jensen gcc/config/i386 * i386.cc (expand_vec_perm_movs): New method matching movs patterns

Re: O2 Agressive Optimisation by GCC

On Sonntag, 22. Juli 2018 17:01:29 CEST Umesh Kalappa wrote: > Allan , > > >>he might as well go traditional > > you mean using the locks ? > No I am meant relying on undefined behavior. In your case I would recommend using modern atomics, which is defined behavior, and modern and fast. I was

Re: O2 Agressive Optimisation by GCC

On Samstag, 21. Juli 2018 00:21:48 CEST Jonathan Wakely wrote: > On Fri, 20 Jul 2018 at 23:06, Allan Sandfeld Jensen wrote: > > On Freitag, 20. Juli 2018 14:19:12 CEST Umesh Kalappa wrote: > > > Hi All , > > > > > > We are looking at the C sample i.e > >

Re: O2 Agressive Optimisation by GCC

On Freitag, 20. Juli 2018 14:19:12 CEST Umesh Kalappa wrote: > Hi All , > > We are looking at the C sample i.e > > extern int i,j; > > int test() > { > while(1) > { i++; > j=20; > } > return 0; > } > > command used :(gcc 8.1.0) > gcc -S test.c -O2 > > the generated asm for x86 >

Re: Enabling -ftree-slp-vectorize on -O2/Os

Okay, I think I can withdraw the suggestion. It is apparently not providing a stable end performance. I would like to end with sharing the measurements I made that motivated me to suggest the change. Hopefully it can be useful if tree-slp-vectorize gets improved and the suggestion comes up

Re: Enabling -ftree-slp-vectorize on -O2/Os

On Dienstag, 29. Mai 2018 16:57:56 CEST Richard Biener wrote: > > so the situation improves but isn't fully fixed (STLF issues maybe?) > That raises the question if it helps in these cases even in -O3? Anyway it doesn't look good for it. Did the binary size at least improve with

Re: Enabling -ftree-slp-vectorize on -O2/Os

On Montag, 28. Mai 2018 12:58:20 CEST Richard Biener wrote: > compile-time effects of the patch on that. Embedded folks may want to rhn > their favorite benchmark and report results as well. > > So I did a -O2 -march=haswell [-ftree-slp-vectorize] SPEC CPU 2006 compile > and run and the

Re: Enabling -ftree-slp-vectorize on -O2/Os

On Sonntag, 27. Mai 2018 03:23:36 CEST Segher Boessenkool wrote: > On Sun, May 27, 2018 at 01:25:25AM +0200, Allan Sandfeld Jensen wrote: > > On Sonntag, 27. Mai 2018 00:05:32 CEST Segher Boessenkool wrote: > > > On Sat, May 26, 2018 at 11:32:29AM +0200, Allan Sandfeld Jense

Re: Enabling -ftree-slp-vectorize on -O2/Os

On Sonntag, 27. Mai 2018 00:05:32 CEST Segher Boessenkool wrote: > On Sat, May 26, 2018 at 11:32:29AM +0200, Allan Sandfeld Jensen wrote: > > I brought this subject up earlier, and was told to suggest it again for > > gcc 9, so I have attached the preliminary changes. > > >

Enabling -ftree-slp-vectorize on -O2/Os

I brought this subject up earlier, and was told to suggest it again for gcc 9, so I have attached the preliminary changes. My studies have show that with generic x86-64 optimization it reduces binary size with around 0.5%, and when optimizing for x64 targets with SSE4 or better, it reduces

Re: [Patch] Request for comments: short int builtins

On Sonntag, 20. Mai 2018 15:07:59 CEST Richard Biener wrote: > On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen <li...@carewolf.com> wrote: > >A little over a year back we had a regression in a point release of gcc > > > >because the builtin __builtin

[Patch] Request for comments: short int builtins

A little over a year back we had a regression in a point release of gcc because the builtin __builtin_clzs got removed from i386, in part because it is was wrongly named for a target specific builtin, but we were using it in Qt since it existed in multiple compilers. I got the patch removing it

Re: [PATCH] Use two source permute for vector initialization (PR 85692, take 2)

On Donnerstag, 10. Mai 2018 09:57:22 CEST Jakub Jelinek wrote: > On Wed, May 09, 2018 at 04:53:19PM +0200, Allan Sandfeld Jensen wrote: > > > > @@ -2022,8 +2022,9 @@ simplify_vector_constructor > > > > (gimple_stmt_iterator > > > > *gsi)> >

Re: [Patch] Use two source permute for vector initialization (PR 85692)

On Mittwoch, 9. Mai 2018 11:08:02 CEST Jakub Jelinek wrote: > On Tue, May 08, 2018 at 01:25:35PM +0200, Allan Sandfeld Jensen wrote: > > 2018-05-08 Allan Sandfeld Jensen <allan.jen...@qt.io> > > 2 spaces between date and name and two spaces between name and email >

Re: [Patch] Use two source permute for vector initialization (PR 85692)

On Dienstag, 8. Mai 2018 12:42:33 CEST Richard Biener wrote: > On Tue, May 8, 2018 at 12:37 PM, Allan Sandfeld Jensen > > <li...@carewolf.com> wrote: > > I have tried to fix PR85692 that I opened. > > Please add a testcase as well. It also helps if you shortly

[Patch] Use two source permute for vector initialization (PR 85692)

I have tried to fix PR85692 that I opened. 2018-05-08 Allan Sandfeld Jense PR tree-optimization/85692 * tree-ssa-forwprop.c (simplify_vector_constructor): Detect two source permute operations as well. diff --git a/gcc/tree-ssa-forwprop.c

Re: Resolving LTO symbols for static library boundary

On Dienstag, 6. Februar 2018 01:01:29 CET Jan Hubicka wrote: > Dne 2018-02-05 18:44, Richard Biener napsal: > > On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen > > > > <li...@carewolf.com> wrote: > >> Hello GCC > >> > >> In t

Resolving LTO symbols for static library boundary

Hello GCC In trying to make it possible to use LTO for distro-builds of Qt, I have again hit the problem of static libraries. In Qt in general we for LTO rely on a library boundary, where LTO gets resolved when generating the library but no LTO-symbols are exported in the shared library. This

Re: RFC: Improving GCC8 default option settings

On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote: > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote: > > On its own -O3 doesn't add much (some loop opts and slightly more > > aggressive inlining/unrolling), so whatever it does we > > should consider doing at -O2

Re: RFC: Improving GCC8 default option settings

On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote: > > On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote: > > > > Hi all, > > > > At the GNU Cauldron I was inspired by several interesting talks about > > improving GCC in various ways. While GCC has many

Re: Quantitative analysis of -Os vs -O3

On Samstag, 26. August 2017 12:59:06 CEST Markus Trippelsdorf wrote: > On 2017.08.26 at 12:40 +0200, Allan Sandfeld Jensen wrote: > > On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote: > > > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > > &

Re: Quantitative analysis of -Os vs -O3

On Samstag, 26. August 2017 10:56:16 CEST Markus Trippelsdorf wrote: > On 2017.08.26 at 01:39 -0700, Andrew Pinski wrote: > > First let me put into some perspective on -Os usage and some history: > > 1) -Os is not useful for non-embedded users > > 2) the embedded folks really need the smallest

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

On Tuesday 09 May 2017, Daniel Santos wrote: > The primary aim is to facilitate high-performance generic C > libraries for software where C++ is not suitable, but the cost of > run-time abstraction is unacceptable. A good example is the Linux > kernel, where the source tree is littered with more

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Tuesday 02 May 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 03:15:11PM +0200, Allan Sandfeld Jensen wrote: > > Okay, I have tried that, and I also made it more obvious how the > > intrinsics can become non-immediate shift. > > > > > > diff --gi

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > --- a/gcc/config/i386/avx2intrin.h > > +++ b/gcc/config/i386/avx2intrin.h > > @@ -667,7 +667,7 @@ extern __inline __m256i > > > >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 11:01:29AM +0200, Allan Sandfeld Jensen wrote: > > On Monday 24 April 2017, Jakub Jelinek wrote: > > > On Mon, Apr 24, 2017 at 10:34:58AM +0200, Allan Sandfeld Jensen wrote: > > > > T

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 10:34:58AM +0200, Allan Sandfeld Jensen wrote: > > That is a different instruction. That is the vpsllw not vpsllwi > > > > The intrinsics I changed is the immediate version, I didn't change the >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Allan Sandfeld Jensen wrote: > On Monday 24 April 2017, Jakub Jelinek wrote: > > On Mon, Apr 24, 2017 at 10:02:40AM +0200, Allan Sandfeld Jensen wrote: > > > > That said, both the options I've mentioned above provide the same > > &g

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 10:02:40AM +0200, Allan Sandfeld Jensen wrote: > > > That said, both the options I've mentioned above provide the same > > > advantages and don't have the disadvantages of pessimizing normal code. >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:51:29AM +0200, Allan Sandfeld Jensen wrote: > > On Monday 24 April 2017, Jakub Jelinek wrote: > > > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > > > ---

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Monday 24 April 2017, Jakub Jelinek wrote: > On Mon, Apr 24, 2017 at 09:33:09AM +0200, Allan Sandfeld Jensen wrote: > > --- a/gcc/config/i386/avx2intrin.h > > +++ b/gcc/config/i386/avx2intrin.h > > @@ -667,7 +667,7 @@ extern __inline __m256i > > > >

Re: [PATCH] [x86] Avoid builtins for SSE/AVX2 immidiate logical shifts

On Saturday 22 April 2017, Allan Sandfeld Jensen wrote: > Replaces definitions of immediate logical shift intrinsics with GCC > extension syntax. Tests are added to ensure the intrinsics still produce > the right instructions and that a few basic optimizations now work. >

Re: C++17 by default in gcc-8

On Sunday 26 March 2017, Egor Pugin wrote: > Hi, > > It's a bit early question, but still. > C++ releases became more predictive and regular. > What do you think about settings -std=c++17 (or gnu++17) for gcc-8 as > default c++ mode? > What is your policy regarding default c++ standards in gcc?

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

On Tuesday 06 December 2016, Uros Bizjak wrote: > Hello! > > > 2016-11-30 Allan Sandfeld Jensen <allan.jen...@qt.io> > > > >PR target/70118 > >* gcc/config/i386/mmintrin.h (__m64_u): New type > >* gcc/config/i386/emmi

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

Trying again, this time with changelog. gcc/ 2016-11-30 Allan Sandfeld Jensen <allan.jen...@qt.io> PR target/70118 * gcc/config/i386/mmintrin.h (__m64_u): New type * gcc/config/i386/emmintrin.h (_mm_loadl_epi64, _mm_storel_epi64): Make the allowed una

Re: [PING][RFC] Assertions as optimization hints

On Wednesday 23 November 2016, Richard Biener wrote: > On Tue, Nov 22, 2016 at 6:52 PM, Yuri Gribov wrote: > > Hi all, > > > > I've recently revisited an ancient patch from Paolo > > (https://gcc.gnu.org/ml/gcc-patches/2004-04/msg00551.html) which uses > > asserts as

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

On Sunday 27 November 2016, Marc Glisse wrote: > On Sat, 26 Nov 2016, Allan Sandfeld Jensen wrote: > > Use the recently introduced unaligned variant of __m128i and add a > > similar __m64 and use those to make it clear these two intrinsics > > require neither 128- bit

[Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

Use the recently introduced unaligned variant of __m128i and add a similar __m64 and use those to make it clear these two intrinsics require neither 128- bit nor 64-bit alignment. `Allan Index: gcc/config/i386/emmintrin.h === ---

Re: [PATCH] libiberty: Fix -Wimplicit-fallthrough warnings.

On Wednesday 02 November 2016, Mark Wielaard wrote: > -case 11: c+=((hashval_t)k[10]<<24); > -case 10: c+=((hashval_t)k[9]<<16); > -case 9 : c+=((hashval_t)k[8]<<8); > +case 11: c+=((hashval_t)k[10]<<24); /* fall through */ > +case 10: c+=((hashval_t)k[9]<<16); /*

Re: [PATCH] Introduce -Wimplicit-fallthrough={0,1,2,3,4,5}

On Tuesday 11 October 2016, Jakub Jelinek wrote: > Hi! > > The following patch introduces difference warning levels for > -Wimplicit-fallthrough warning, so projects can choose if they want to > honor only attributes (-Wimplicit-fallthrough=5), or what kind of comments. > =4 is very picky and

Re: Constexpr in intrinsics?

On Sunday 27 March 2016, Marc Glisse wrote: > On Sun, 27 Mar 2016, Allan Sandfeld Jensen wrote: > > Would it be possible to add constexpr to the intrinsics headers? > > > > For instance _mm_set_XX and _mm_setzero intrinsics. > > Already suggested here: > https://gcc

Constexpr in intrinsics?

Would it be possible to add constexpr to the intrinsics headers? For instance _mm_set_XX and _mm_setzero intrinsics. Ideally it could also be added all intrinsics that can be evaluated at compile time, but it is harder to tell which those are. Does gcc have a C extension we can use to set

Re: Change to C++11 by default?

On Thursday 07 May 2015, Jason Merrill wrote: I think it's time to switch to C++11 as the default C++ dialect for GCC 6. Any thoughts? Would it be unrealistic to make C++14 the default? With it being an fixup of C++11, I would guess it could have longer staying power as the default. `Allan

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: On Monday 26 January 2015, H.J. Lu wrote: On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: Committed with a bunch of fixes

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, you wrote: On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen al...@carewolf.com wrote: On Monday 26 January 2015, H.J. Lu wrote: On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen carew...@gmail.com wrote: Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to missing

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Monday 26 January 2015, H.J. Lu wrote: On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak ubiz...@gmail.com wrote: On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen al...@carewolf.com wrote: On Saturday 24

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Saturday 24 January 2015, Uros Bizjak wrote: On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak ubiz...@gmail.com wrote: Hello! On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

On Wednesday 31 December 2014, Jakub Jelinek wrote: On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, and also added AES, F16C

[Patch, i386] Support AES, F16C, BMI and BMI2 targets in multiversioning

I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, and also added AES, F16C and BMI1 for completeness. Happy new year `Allan commit 062c09d45d22302ffbd4f86d88e16a1a0d49cd80 Author: Allan Sandfeld Jensen

Re: [Patch, i386] Support AES, F16C, BMI and BMI2 targets in multiversioning

On Wednesday 31 December 2014, Jakub Jelinek wrote: On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote: I recently wanted to use multiversioning for BMI2 specific extensions PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add it, and also added AES, F16C

Optimizing bit extract

Hello gcc I have been looking at optimizations of pixel-format conversion recently and have noticed that gcc does take advantage of SSE4a extrq, BMI1 bextr TBM bextri or BMI2 pext instructions when it could be useful. As far as I can tell it should not be that hard. A bextr expression can

Re: [Patch, i386] Separate Intel processor with expanded ISA

Updated patch with test. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index ccbea0f..e80c30b 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org + * config/i386/i386.c (get_builtin_code_for_version): Separate + Westmere from Nehalem

Re: [Patch, i386] Separate Intel processor with expanded ISA

No comments? On Sunday 29 December 2013, Allan Sandfeld Jensen wrote: The function dispatcher might currently choose functions declared with target(arch=ivybridge) on a Sandy Bridge CPU. This happens because the function is only detected as sandybridge when generated. The attached patch

[Patch, i386] Separate Intel processor with expanded ISA

they support. Regards `Allan Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 206233) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2013-12-29 Allan Sandfeld Jensen sandf...@kde.org + + * config/i386/i386.c

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

On Thursday 26 December 2013, Gopalasubramanian, Ganesh wrote: Hi, (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and AMDFAM15H_BDVER3. As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead of using BOBCAT or JAGUAR. Attached patch does the

  1   2   >