Re: [C++ PATCH] Allow [[likely]] and [[unlikely]] in constexpr functions (PR c++/92343)

OK. I wonder why we're returning false for EMPTY_CLASS_EXPR? On Tue, Nov 5, 2019 at 7:35 AM Jakub Jelinek wrote: > > Hi! > > When Martin Liska added PREDICT_EXPR to potential_constant_expression_1, > it was with goto in mind and in that case goto isn't a potential > constant expression, but when

Re: [PATCH] Fix compute_objsize ICE on VLA ARRAY_REF (PR tree-optimization/91945)

On Tue, 5 Nov 2019, Jakub Jelinek wrote: > Hi! > > As the testcase shows, ARRAY_REF on an array with variable length element > doesn't have INTEGER_CST TYPE_SIZE_UNIT which the code was assuming. > The following patch punts in that case. > > Bootstrapped/regtested on x86_64-linux and i686-linux,

Re: [PATCH] Reject VLAs in inline asm operands that require registers (PR inline-asm/92352)

On Tue, 5 Nov 2019, Jakub Jelinek wrote: > Hi! > > On VLAs with register only constraints we ICE, because during gimplification > we try to create temporaries for them and force_constant_size aborts in that > case. > > The following patch diagnoses those early, like we diagnose already C++ > non

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Segher Boessenkool writes: > Hi! > > On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >> In this patch, loop unroll adjust hook is introduced for powerpc. We can do >> target related hueristic adjustment in this hook. In this patch, small loops >> is unrolled 2 times for O2 and O3 by d

Re: [PATCH rs6000]Fix PR92132

Hi Segher, Thanks for the comments! on 2019/11/2 上午7:17, Segher Boessenkool wrote: > On Tue, Oct 29, 2019 at 01:16:53PM +0800, Kewen.Lin wrote: >> (vcond_mask_): New expand. > > Say for which mode please? Like > (vcond_mask_ for VEC_I and VEC_I): New expand. > Fixed as below. >>

Re: [PATCH] Fix hash_operand for fields of a CONSTRUCTOR.

On 11/4/19 4:24 PM, Jeff Law wrote: On 11/4/19 6:36 AM, Richard Biener wrote: On Mon, Nov 4, 2019 at 2:35 PM Richard Biener wrote: On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wrote: On 11/1/19 10:51 PM, Jeff Law wrote: On 10/31/19 10:01 AM, Martin Liška wrote: Hi. operand_equal_p can p

[PATCH][OBVIOUS] Remove FIELD_DECL leftover.

Hi. The patch installed as r277614 is not exactly 1:1 to the previous revision, but I forgot to remove hashing of FIELD_DECL. The tree type is not handled in operand_equal_p. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I'm going to install it as obvious. Thanks, Marti

Re: Optimize handling of inline summaries

On 11/4/19 8:09 PM, Jan Hubicka wrote: On 11/4/19 3:12 PM, Jan Hubicka wrote: Martin, do you know why this flag was introduced? Hi. The flag is used in IPA CP: call_summary class edge_clone_summary { ... cgraph_edge *prev_clone; cgraph_edge *next_clone; } I see, so it is there to c

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Richard Biener writes: > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > >> Hi! >> >> On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >> > In this patch, loop unroll adjust hook is introduced for powerpc. We can >> > do >> > target related hueristic adjustment in this hook. In this

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: > Segher Boessenkool writes: > >> Hi! >> >> On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote: >>> In this patch, loop unroll adjust hook is introduced for powerpc. We can do >>> target related hueristic adjustment in this hook. In this patch, small loops >>> is unroll

Re: Ping: [PATCH V6] Extend IPA-CP to support arithmetically-computed value-passing on by-ref argument (PR ipa/91682)

Hi Martin, Thanks for your review. I updated the patch with your comments. Feng > Sorry that it took so long. Next time, please consider making the > review a bit easier by writing a ChangeLog (yes, I usually read them and > you'll have to write one anyway). >> + class ipcp_param_l

[committed] move vrp_set_zero_nonzero_bits into vr-values.c

This function is only used in vr-values.c, so it doesn't need to be externally visible or defined in tree-vrp.c. In moving it I noticed that wide_int_range_set_zero_nonzero_bits is redundant, as we can grab the version in range-op. I've also renamed the function to vr_set_zero_nonzero_bits (r

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

On 25/10/2019 09:03, Tobias Burnus wrote: Hello Mark, hi all, On 10/21/19 4:40 PM, Mark Eggleston wrote: This is an extension to support a legacy feature supported by other compilers such as flang and the sun compiler.  As I understand it this feature is associated with DEC so it enabled usin

Re: [PATCH] Reject VLAs in inline asm operands that require registers (PR inline-asm/92352)

On Tue, Nov 05, 2019 at 09:27:45AM +0100, Richard Biener wrote: > > --- gcc/gimplify.c.jj 2019-11-02 10:00:59.595253274 +0100 > > +++ gcc/gimplify.c 2019-11-05 00:21:01.585958514 +0100 > > @@ -6235,8 +6235,14 @@ gimplify_asm_expr (tree *expr_p, gimple_ > > is_inout = false; > > } >

Add object allocators to symbol and call summaries

Hi, this patch adds object allocators to manage IPA summaries. This reduces malloc overhead and fragmentation. I now get peak memory use 7.5GB instead of 10GB for firefox WPA because reduced fragmentation leads to less COWs after forks. Additional bonus is that we now have statistics gathered b

Free memory used by optimization/target options

Hi, this fixes memory leak for xstrduped strings in option summaries which may get ggc_freed by tree merging. Bootstrapped/regtested x86_64-linux, OK? Honza * optc-save-gen.awk: Generate cl_target_option_free and cl_optimization_option_free. * opth-en.awk: Declare cl_targ

Re: [PATCH] Reject VLAs in inline asm operands that require registers (PR inline-asm/92352)

On Tue, 5 Nov 2019, Jakub Jelinek wrote: > On Tue, Nov 05, 2019 at 09:27:45AM +0100, Richard Biener wrote: > > > --- gcc/gimplify.c.jj 2019-11-02 10:00:59.595253274 +0100 > > > +++ gcc/gimplify.c2019-11-05 00:21:01.585958514 +0100 > > > @@ -6235,8 +6235,14 @@ gimplify_asm_expr (tree *e

Add obstack for canonical file name hash table

Hi, looking into malloc overhead I noticed that we do a lot of small allocations to hold file names comming from location info. This patch puts it into an obstack so it interleaves memory allocated by scc_hash less frequently. (Still we end up interleaving 64k pages which are permanent - in fact th

Re: Add object allocators to symbol and call summaries

On 11/5/19 11:36 AM, Jan Hubicka wrote: Hi, this patch adds object allocators to manage IPA summaries. This reduces malloc overhead and fragmentation. I now get peak memory use 7.5GB instead of 10GB for firefox WPA because reduced fragmentation leads to less COWs after forks. That sounds promi

Re: Free memory used by optimization/target options

On Tue, 5 Nov 2019, Jan Hubicka wrote: > Hi, > this fixes memory leak for xstrduped strings in option summaries which may > get ggc_freed by tree merging. > > Bootstrapped/regtested x86_64-linux, OK? OK. If those are ever reaped by regular GC the memory still leaks, no? So wouldn't it be better

Re: Free memory used by optimization/target options

> On Tue, 5 Nov 2019, Jan Hubicka wrote: > > > Hi, > > this fixes memory leak for xstrduped strings in option summaries which may > > get ggc_freed by tree merging. > > > > Bootstrapped/regtested x86_64-linux, OK? > > OK. If those are ever reaped by regular GC the memory still leaks, no? > So w

Re: Add object allocators to symbol and call summaries

On 11/5/19 11:45 AM, Martin Liška wrote: Please rename allocator to m_allocator. You were faster and installed that patch. Thus I'm sending the adjustment. Martin >From 6edd5d8c4afb0451aaaf05ba857435219b31814d Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Tue, 5 Nov 2019 11:50:32 +0100 S

Re: Add obstack for canonical file name hash table

On Tue, 5 Nov 2019, Jan Hubicka wrote: > Hi, > looking into malloc overhead I noticed that we do a lot of small > allocations to hold file names comming from location info. This patch > puts it into an obstack so it interleaves memory allocated by scc_hash > less frequently. > (Still we end up int

[PATCH] Fix part of PR92324

We have to be able to choose one signedness for the epilogue part of the reduction - for MIN/MAX this means if we have two both have to be of the same signedness. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2019-11-05 Richard Biener PR tree-optimization/9

Re: Add object allocators to symbol and call summaries

> On 11/5/19 11:36 AM, Jan Hubicka wrote: > > Hi, > > this patch adds object allocators to manage IPA summaries. This reduces > > malloc overhead and fragmentation. I now get peak memory use 7.5GB instead > > of 10GB for firefox WPA because reduced fragmentation leads to less COWs > > after > > f

Re: Add object allocators to symbol and call summaries

> On 11/5/19 11:45 AM, Martin Liška wrote: > > Please rename allocator to m_allocator. > > You were faster and installed that patch. > > Thus I'm sending the adjustment. > > Martin > From 6edd5d8c4afb0451aaaf05ba857435219b31814d Mon Sep 17 00:00:00 2001 > From: Martin Liska > Date: Tue, 5 Nov

Re: Add obstack for canonical file name hash table

> On Tue, 5 Nov 2019, Jan Hubicka wrote: > > > Hi, > > looking into malloc overhead I noticed that we do a lot of small > > allocations to hold file names comming from location info. This patch > > puts it into an obstack so it interleaves memory allocated by scc_hash > > less frequently. > > (Sti

[PATCH 1/X][mid-end] Fix declared type of personality functions

`build_personality_function` generates a declaration for a personality function. The type it declares for these functions doesn't match the type of the actual personality functions that are defined by the C++ unwinding ABI. This doesn't cause any crashes since the compiler never generates a call

[PATCH 2/X] [libsanitizer] Introduce libhwasan to GCC tree

Takes the libhwasan library from LLVM and puts it into our source tree excluding the build system files. Tieing the source files into our build system is done in a later commit. We have taken the libsanitizer library from the same SVN revision as the other sanitizer libraries are taken from (SVN

[aarch64] Allocate enough space for err_str in aarch64_handle_attr_branch_protection

-fsanitize=hwaddress found a one-byte overwrite when running the testsuite here. aarch64_handle_attr_branch_protection allocates `strlen(str)` bytes for an error string, which is populated by `strcpy(..., str)` in the case where the branch protection string is completely invalid. Tested on aarch6

[PATCH 5/X] [libsanitizer] Remove system allocator fallback

Backport from llvm-svn: 375296. This was an experiment made possible by a non-standard feature of the Android dynamic loader. Going without that experiment makes implementation for glibc easier. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan_allocator.cpp (hwasa

[PATCH 3/X] [libsanitizer] libhwasan initialisation include kernel syscall ABI relaxation

Backported from LLVM-svn 375166. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan.cc (InitInstrumentation): Call InitPrctl. * hwasan/hwasan.h (InitPrctl): New decl. * hwasan/hwasan_linux.cc (InitPrctl): New function. ### Attachmen

[PATCH 4/X] [libsanitizer] libhwasan add longjmp & setjmp interceptors

Backported from LLVM git id 67474c60d libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan.h (__hw_jmp_buf_struct, __hw_jmp_buf, __hw_sigjmp_buf): Define new types for internal longjmp implementation. * hwasan/hwasan_interceptors.cpp (__sigjmp_s

[PATCH 9/X] [libsanitizer] Remove lazy thread initialisation

Backport from llvm upstream (monorepo revision 91167e2). This was an experiment made possible by a non-standard feature of the Android dynamic loader. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan_interceptors.cpp (HwasanThreadStartFunc): Re-introduce.

[PATCH 7/X] [libsanitizer] Add missing SANITIZER_INTERFACE_ATTRIBUTE on __hwasan_personality_wrapper

Backport from llvm upstream llvm-svn: 375298. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan_exceptions.cpp (__hwasan_personality_wrapper): Add missing interface attribute. ### Attachment also inlined for ease of reply##

[PATCH 6/X] [libsanitizer] Add hwasan_exceptions.cpp file

This is needed for the hwasan_personality instrumentation I've added. Backported from llvm-svn: 369721 libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan_exceptions.cpp: New file. ### Attachment also inlined for ease of reply### d

[PATCH 8/X] [libsanitizer] Expose __hwasan_tag_mismatch_stub

Backport from llvm upstream (monorepo revision 612eadb). This allows us to report tag mismatches without threading it through the backend to generate assembly. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * hwasan/hwasan_interface_internal.h (__hwasan_tag_mismatch4): N

[PATCH 10/X] [libsanitizer] Tie the hwasan library into our build system

This patch does tries to tie libhwasan into the GCC build system in the same way that the other sanitizer runtime libraries are handled. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * Makefile.am: Build libhwasan. * Makefile.in: Build libhwasan. * asan/Makefi

[PATCH 12/X] [libsanitizer] Add option to bootstrap using HWASAN

This is an analogous option to --bootstrap-asan to configure. It allows bootstrapping GCC using HWASAN. For the same reasons as for ASAN we have to avoid using the HWASAN sanitizer when compiling libiberty and the lto-plugin. Also add a function to query whether -fsanitize=hwaddress has been pas

[PATCH 11/X] [libsanitizer] Only build libhwasan when targeting AArch64

Though the library has limited support for x86, we don't have any support for generating code targeting x86 so there is no point building for that target. libsanitizer/ChangeLog: 2019-11-05 Matthew Malcomson * Makefile.am: Condition building hwasan directory. * Makefile.in: Re

[PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing

These flags can't be used at the same time as any of the other sanitizers. We add an equivalent flag to -static-libasan in -static-libhwasan to ensure static linking. The -fsanitize=kernel-hwaddress option is for compiling targeting the kernel. This flag has defaults that allow compiling KASAN wi

[PATCH 15/X] [libsanitizer] Add hwasan pass and associated gimple changes

There are four main features to this change: 1) Check pointer tags match address tags. In the new `hwasan` pass we put HWASAN_CHECK internal functions around all memory accesses, to check that tags in the pointer being used match the tag stored in shadow memory for the memory region being used.

[PATCH 14/X] [libsanitizer][mid-end] Introduce stack variable handling for HWASAN

Handling stack variables has three features. 1) Ensure HWASAN required alignment for stack variables When colouring shadow memory, we need to ensure that each tag granule is only used by one variable at a time. This is done by ensuring that each coloured variable is aligned to the tag granule re

[PATCH 17/X] [libsanitizer] Add hwasan Exception handling

When tagging the stack we need to ensure that any stack frames are untagged during unwinding of any sort. If this is not done, then functions called later which re-use the stack can observe tag mismatches on accesses to memory they have not tagged but that has been tagged previously. This applies

[PATCH 18/X] [libsanitizer] Add in MTE stubs

This patch in the series is just for demonstration, here we add stubs where MTE would be implemented. We also add a new flag to request memory tagging as a sanitizer option. The new flag for memory tagging is `-fsanitize=memtag`, which is in line with the flag clang uses to request memory tagging.

[PATCH 16/X] [libsanitizer] Add tests

Adding hwasan tests. Frankly, these could be tidied up a little. I will be tidying them up while getting feedback on the hwasan introduction. gcc/testsuite/ChangeLog: 2019-11-05 Matthew Malcomson * c-c++-common/hwasan/arguments.c: New test. * c-c++-common/hwasan/halt_on_erro

Re: Add obstack for canonical file name hash table

On Tue, 5 Nov 2019, Jan Hubicka wrote: > > On Tue, 5 Nov 2019, Jan Hubicka wrote: > > > > > Hi, > > > looking into malloc overhead I noticed that we do a lot of small > > > allocations to hold file names comming from location info. This patch > > > puts it into an obstack so it interleaves memory

Re: [aarch64] Allocate enough space for err_str in aarch64_handle_attr_branch_protection

Hi Matthew, On 11/5/19 11:33 AM, Matthew Malcomson wrote: > -fsanitize=hwaddress found a one-byte overwrite when running the > testsuite here.  aarch64_handle_attr_branch_protection allocates > `strlen(str)` bytes for an error string, which is populated by > `strcpy(..., str)` in the case where th

Re: [PATCH 1/X][mid-end] Fix declared type of personality functions

On Tue, 5 Nov 2019, Matthew Malcomson wrote: > `build_personality_function` generates a declaration for a personality > function. The type it declares for these functions doesn't match the > type of the actual personality functions that are defined by the C++ > unwinding ABI. > > This doesn't ca

Re: [PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

Hi Andrew, Anton, On 11/1/19 11:22 PM, Andrew Pinski wrote: > On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch > wrote: > > > > Hello, > > > > Here is the one-liner that fixes the incorrect > > vec_perm cost for thunderx2t99 chip. > > With the patch applied 526.blender of CPU2017 > > gets ~5% imp

Re: r272976 - in /trunk/gcc/ada: ChangeLog ali.adb ...

> That should be @uref{prerequisites.html#GNAT-prerequisite,,GNAT > prerequisites}. Thanks. I wouldn't have been able to guess that! Corresponding patch installed. 2019-11-05 Arnaud Charlet * doc/install.texi: Further fix syntax for html generation. Index: doc/install.texi

Re: [PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

Andrew, On 02.11.2019 2:22, Andrew Pinski wrote: On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch wrote: Hello, Here is the one-liner that fixes the incorrect vec_perm cost for thunderx2t99 chip. With the patch applied 526.blender of CPU2017 gets ~5% improvement with no measurable changes fo

Re: [C++ PATCH] Allow [[likely]] and [[unlikely]] in constexpr functions (PR c++/92343)

On Tue, Nov 05, 2019 at 08:19:17AM +, Jason Merrill wrote: > OK. Thanks, committed. > I wonder why we're returning false for EMPTY_CLASS_EXPR? No idea. Seems it has been added in http://gcc.gnu.org/r227296 on c++-delayed-folding branch by Kai, but there was no testsuite coverage nor I can

Re: [PATCH 0/X] Introduce HWASAN sanitizer to GCC

On 05/11/2019 11:32, Matthew Malcomson wrote: > > Testing done: > Full bootstrap and regtest on x86_64 (no difference -- hwasan not used). > > Full bootstrap and regtest on AArch64 sanitizing with hwasan and running > on recent kernel. > Regressions all accounted for: >1) tests under plugin/

Re: [PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

Kyrill, On 05.11.2019 14:43, Kyrylo Tkachov wrote: Hi Andrew, Anton, On 11/1/19 11:22 PM, Andrew Pinski wrote: On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch wrote: Hello, Here is the one-liner that fixes the incorrect vec_perm cost for thunderx2t99 chip. With the patch applied 526.blend

Re: Add object allocators to symbol and call summaries

On 11/5/19 12:01 PM, Jan Hubicka wrote: On 11/5/19 11:36 AM, Jan Hubicka wrote: Hi, this patch adds object allocators to manage IPA summaries. This reduces malloc overhead and fragmentation. I now get peak memory use 7.5GB instead of 10GB for firefox WPA because reduced fragmentation leads to l

Re: [PR47785] COLLECT_AS_OPTIONS

On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah wrote: > > Hi, > Thanks for the review. > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu wrote: > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan Vivekanandarajah > > wrote: > > > > > > Thanks for the reviews. > > > > > > > > > On Sat, 2 Nov 2019 at 02:4

Re: [PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

On 11/5/19 11:54 AM, Anton Youdkevitch wrote: Kyrill, On 05.11.2019 14:43, Kyrylo Tkachov wrote: > Hi Andrew, Anton, > > On 11/1/19 11:22 PM, Andrew Pinski wrote: >> On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch >> wrote: >>> >>> Hello, >>> >>> Here is th

[RFC PATCH] Extend the simd function attribute

(sorry for the resend, i forgot to add the mailing list) GCC currently supports two ways to declare the availability of vector variants of a scalar function: #pragma omp declare simd void f (void); and __attribute__ ((simd)) void f (void); However neither can declare unambiguously a si

[PATCH 2/5] Update Makefile.am.

libsanitizer/ChangeLog: 2019-11-05 Martin Liska * tsan/Makefile.am: Rename tsan_interceptors.cpp to tsan_interceptors_posix. * tsan/Makefile.in: Regenerate. --- libsanitizer/tsan/Makefile.am | 2 +- libsanitizer/tsan/Makefile.in | 6 +++--- 2 files changed, 4 insertio

[PATCH 4/5] Set print_summary for UBSAN.

libsanitizer/ChangeLog: 2019-11-05 Martin Liska * ubsan/ubsan_flags.cpp (InitializeFlags): Trunk decided to print summary for all sanitizers, but we want to have UBSAN without it. --- libsanitizer/ubsan/ubsan_flags.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/libsa

[PATCH 0/5] libsanitizer: merge from trunk

Hi. I've just done merge from trunk for libsanitizer. I bootstrapped the patch set on x86_64-linux-gnu and run asan/ubsan/tsan tests on x86_64, ppc64le (power8) and aarch64. Plus I run ubsan and asan boostrap on ppc64le-linux-gnu and abidiff is fine comparing the current trunk with the merged li

[PATCH 3/5] Reapply all revisions mentioned in LOCAL_PATCHES.

libsanitizer/ChangeLog: 2019-11-05 Martin Liska * asan/asan_globals.cpp (CheckODRViolationViaIndicator): Reapply from LOCAL_PATCHES. (CheckODRViolationViaPoisoning): Likewise. (RegisterGlobal): Likewise. * asan/asan_interceptors.h (ASAN_INTERCEPT___CXA

[PATCH 5/5] Update scanned patterns in a test-case.

gcc/testsuite/ChangeLog: 2019-11-05 Martin Liska * c-c++-common/ubsan/ptr-overflow-2.c: Update based on changed run-time reporting format. --- gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/gcc/

Re: [PATCH][Aarch64] Fix vec_perm cost for thunderx2t99

On 05.11.2019 15:09, Kyrylo Tkachov wrote: On 11/5/19 11:54 AM, Anton Youdkevitch wrote: Kyrill, On 05.11.2019 14:43, Kyrylo Tkachov wrote: > Hi Andrew, Anton, > > On 11/1/19 11:22 PM, Andrew Pinski wrote: >> On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch >> wrote: >>> >>> Hello, >>> >>>

Re: [PATCH 1/5] Libsanitizer: merge from trunk with merge.sh.

On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote: > > libsanitizer/ChangeLog: > > 2019-11-05 Martin Liska > > * all source files: Merge from upstream r375507. > --- > libsanitizer/BlocksRuntime/Block.h| 59 + > libsanitizer/BlocksRuntime/Block_private.h|

Re: [PATCH v2] PR85678: Change default to -fno-common

On Mon, Nov 4, 2019 at 3:39 PM Wilco Dijkstra wrote: > > Hi Richard, > > >> > Please don't add -fcommon in lto.exp. > >> > >> So what is the best way to add an extra option to lto.exp? > >> Note dg-lto-options completely overrides the options from lto.exp, so I > >> can't > >> use that except in

Re: [PATCH] Add if-chain to switch conversion pass.

On Mon, Nov 4, 2019 at 3:49 PM Jakub Jelinek wrote: > > On Mon, Nov 04, 2019 at 03:23:20PM +0100, Martin Liška wrote: > > The patch adds a new pass that identifies a series of if-elseif > > statements and transform then into a GIMPLE switch (if possible). > > The pass runs right after tree-ssa pas

[PATCH][OBVIOUS] Use more ggc_delete.

Hi. It's a small refactoring patch that I've just tested. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I'm going to install the patch. Thanks, Martin gcc/ChangeLog: 2019-11-05 Martin Liska * symbol-summary.h: Use ggc_delete. --- gcc/symbol-summary.h | 10

Re: [9/n] Replace vec_info::vector_size with vec_info::vector_mode

On Fri, Oct 25, 2019 at 2:39 PM Richard Sandiford wrote: > > This patch replaces vec_info::vector_size with vec_info::vector_mode, > but for now continues to use it as a way of specifying a single > vector size. This makes it easier for later patches to use > related_vector_mode instead. OK. >

Re: [10/n] Make less use of get_same_sized_vectype

On Fri, Oct 25, 2019 at 2:41 PM Richard Sandiford wrote: > > Some callers of get_same_sized_vectype were dealing with operands that > are constant or defined externally, and so have no STMT_VINFO_VECTYPE > available. Under the current model, using get_same_sized_vectype for > that case is equival

Re: [PATCH 1/5] Libsanitizer: merge from trunk with merge.sh.

On 11/5/19 1:23 PM, Jakub Jelinek wrote: On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote: libsanitizer/ChangeLog: 2019-11-05 Martin Liska * all source files: Merge from upstream r375507. --- libsanitizer/BlocksRuntime/Block.h| 59 + libsanitizer/Blocks

Re: [11/n] Support vectorisation with mixed vector sizes

On Fri, Oct 25, 2019 at 2:43 PM Richard Sandiford wrote: > > After previous patches, it's now possible to make the vectoriser > support multiple vector sizes in the same vector region, using > related_vector_mode to pick the right vector mode for a given > element mode. No port yet takes advantag

Re: [13/n] Allow mixed vector sizes within a single vectorised stmt

On Fri, Oct 25, 2019 at 2:49 PM Richard Sandiford wrote: > > Although a previous patch allowed mixed vector sizes within a vector > region, we generally still required equal vector sizes within a vector > stmt. Specifically, vect_get_vector_types_for_stmt computes two vector > types: the vector t

Re: [14/n] Vectorise conversions between differently-sized integer vectors

On Fri, Oct 25, 2019 at 2:51 PM Richard Sandiford wrote: > > This patch adds AArch64 patterns for converting between 64-bit and > 128-bit integer vectors, and makes the vectoriser and expand pass > use them. So on GIMPLE we'll see v4si _1; v4di _2; _1 = (v4si) _2; then, correct? Likewise for

Re: PR92163

On Tue, 5 Nov 2019 at 05:46, Prathamesh Kulkarni wrote: > > On Mon, 4 Nov 2019 at 18:37, Christophe Lyon > wrote: > > > > On Mon, 28 Oct 2019 at 16:03, Prathamesh Kulkarni > > wrote: > > > > > > On Mon, 28 Oct 2019 at 07:18, Richard Biener > > > wrote: > > > > > > > > On Fri, Oct 25, 2019 at

Re: [15/n] Consider building nodes from scalars in vect_slp_analyze_node_operations

On Tue, Oct 29, 2019 at 6:04 PM Richard Sandiford wrote: > > If the statements in an SLP node aren't similar enough to be vectorised, > or aren't something the vectoriser has code to handle, the BB vectoriser > tries building the vector from scalars instead. This patch does the > same thing if we

Re: [PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing

On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson wrote: > > These flags can't be used at the same time as any of the other > sanitizers. > We add an equivalent flag to -static-libasan in -static-libhwasan to > ensure static linking. > > The -fsanitize=kernel-hwaddress option is for compiling targ

make range_int_cst_p work with any numeric range (VR_ANTI_RANGE, etc)

The function range_int_cst_p only works with VR_RANGE's at the moment. This is silly because VR_ANTI_RANGE and even VR_VARYING can contain numeric bounds. I have fixed this oversight and have made the function return the bounds in MIN/MAX. This simplifies a lot of code, because there is no lo

Re: [PATCH 1/2] [ARM,testsuite] Skip tests incompatible with -mpure-code

On Mon, 4 Nov 2019 at 17:54, Kyrill Tkachov wrote: > > Hi Christophe, > > On 10/18/19 2:18 PM, Christophe Lyon wrote: > > Hi, > > > > All these tests fail when using -mpure-code: > > * some force A or R profile > > * some use Neon > > * some use -fpic/-fPIC > > all of which are not supported by th

Re: [16/n] Apply maximum nunits for BB SLP

On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford wrote: > > The BB vectoriser picked vector types in the same way as the loop > vectoriser: it picked a vector mode/size for the region and then > based all the vector types off that choice. This meant we could > end up trying to use vector types t

Re: CPUID Patch for IDT Winchip

On Tue, May 21, 2019 at 11:20 AM Uros Bizjak wrote: > > 2019-05-21 Uroš Bizjak > > * config/i386/cpuid.h (__cpuid): For 32bit targets, zero > %ebx and %ecx bafore calling cpuid with leaf 1 or > non-constant leaf argument. > > Bootstrapped and regression tested on x86_64-linux-gnu {,

[PATCH] Fix PR92280

This avoids folding _1 = { _2, _3, _4, _5 }; _2 = BIT_FIELD_REF <_1, ..>; to _1 = { _2, _3, _4, _5 }; _2 = { _4, _5 }; when the first CTOR doesn't become dead. This in turn makes FRE handle partial loads from mem = _1; by inserting BIT_FIELD_REFs on _1 (instead of CTORs which FRE refuses

[Committed 0/4] IBM Z: Fix a few testsuite problems

Andreas Krebbel (4): IBM Z: Use tree_fits_uhwi_p in vector_alignment hook IBM Z: Fix testsuite useable_hw check IBM Z: gen-vect-11/32: Set min-vect-loop-bound param back to default IBM Z: gen-vect-26/28: Vectorizing without peeling is ok for Z gcc/config/s390/s390.c |

[PATCH 2/4] IBM Z: Fix testsuite useable_hw check

This fixes various issues with the useable_hw check in s390.exp. The check is supposed to verify whether a testcase can be run on the current hardware. - the test never returned true for -m31 because vzero is not available in ESA mode and -m31 defaults to -mesa - the missing v0 clobber on the v

[PATCH 3/4] IBM Z: gen-vect-11/32: Set min-vect-loop-bound param back to default

In the Z backend we still set min-vect-loop-bound to 2 to work around corner cases where awkward epilogue code gets generated in the vectorizer. This has a particular bad impact when vectorizing loops with a low iteration count. Due to this we do not vectorize the loop in gen-vect-11/32 - what ac

[PATCH 1/4] IBM Z: Use tree_fits_uhwi_p in vector_alignment hook

This fixes an ICE in gcc.dg/attr-vector_size.c testcase. gcc/ChangeLog: 2019-11-05 Andreas Krebbel * config/s390/s390.c (s390_vector_alignment): Check if the value fits into uhwi before using it. --- gcc/config/s390/s390.c | 8 +++- 1 file changed, 7 insertions(+), 1 dele

[PATCH 4/4] IBM Z: gen-vect-26/28: Vectorizing without peeling is ok for Z

These tests check if loop peeling has been applied to avoid having to vectorize unaligned loops. On Z we do not have any alignment requirements for vectorization so we also don't need want the loop peeling here. 2019-11-05 Andreas Krebbel * gcc.dg/tree-ssa/gen-vect-26.c: Disable loop

Re: [PATCH V4] Loop split upon semi-invariant condition (PR tree-optimization/89134)

On Thu, Oct 31, 2019 at 3:38 PM Feng Xue OS wrote: > > Hi, Richard > >This is a new patch to support more generalized semi-invariant condition, > which uses > control dependence analysis. Uh. Note it's not exactly helpful to change algorithms between reviews, that makes it just harder :/ B

Re: [16/n] Apply maximum nunits for BB SLP

Richard Biener writes: > On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford > wrote: >> >> The BB vectoriser picked vector types in the same way as the loop >> vectoriser: it picked a vector mode/size for the region and then >> based all the vector types off that choice. This meant we could >> en

Re: [PATCH][RFC] Param to options conversion (demo).

On Thu, Oct 31, 2019 at 2:17 PM Martin Liška wrote: > > On 10/31/19 2:16 PM, Martin Liška wrote: > > On 10/31/19 2:01 PM, Martin Liška wrote: > >> Hi. > >> > >> Based on the discussion with Honza and Richard I'm sending a proposal > >> for conversion of param machinery into the existing option mac

Re: [PATCH] Report errors on inconsistent OpenACC nested reduction clauses

Hi Frederik! On 2019-10-29T13:20:53+0100, "Harwath, Frederik" wrote: > On 24.10.19 16:31, Thomas Schwinge wrote: >> So just C/C++ testing, no Fortran at all. This is not ideal, but >> probably (hopefully) acceptable given that this is working on the middle >> end representation shared between a

[0/6] Optionally pick the cheapest loop_vec_info

This series adds a mode in which we try to vectorise loops once for each supported vector mode combination and then pick the one with the lowest cost. There are only really two patches for that: one to add the feature and another to enable it by default for SVE. However, for it to work as hoped,

[1/6] Fix vectorizable_conversion costs

This patch makes two tweaks to vectorizable_conversion. The first is to use "modifier" to distinguish between promotion, demotion, and neither promotion nor demotion, rather than using a code for some cases and "modifier" for others. The second is to take ncopies into account for the promotion an

[2/6] Don't assign a cost to vectorizable_assignment

vectorizable_assignment handles true SSA-to-SSA copies (which hopefully we don't see in practice) and no-op conversions that are required to maintain correct gimple, such as changes between signed and unsigned types. These cases shouldn't generate any code and so shouldn't count against either the

Re: make range_int_cst_p work with any numeric range (VR_ANTI_RANGE, etc)

On Tue, Nov 5, 2019 at 2:15 PM Aldy Hernandez wrote: > > The function range_int_cst_p only works with VR_RANGE's at the moment. > This is silly because VR_ANTI_RANGE and even VR_VARYING can contain > numeric bounds. I have fixed this oversight and have made the function > return the bounds in MIN

[3/6] Avoid accounting for non-existent vector loop versioning

vect_analyze_loop_costing uses two profitability thresholds: a runtime one and a static compile-time one. The runtime one is simply the point at which the vector loop is cheaper than the scalar loop, while the static one also takes into account the cost of choosing between the scalar and vector lo

[4/6] Optionally pick the cheapest loop_vec_info

This patch adds a mode in which the vectoriser tries each available base vector mode and picks the one with the lowest cost. For now the behaviour is behind a default-off --param, but a later patch enables it by default for SVE. The patch keeps the current behaviour of preferring a VF of loop->si

[5/6] Account for the cost of generating loop masks

We didn't take the cost of generating loop masks into account, and so tended to underestimate the cost of loops that need multiple masks. 2019-11-05 Richard Sandiford gcc/ * tree-vect-loop.c (vect_estimate_min_profitable_iters): Include the cost of generating loop masks. gcc/

[6/6][AArch64] Enable vect-compare-loop-costs by default for SVE

This patch enables vect-compare-loop-costs by default for SVE, both so that we can compare SVE against Advanced SIMD and so that (with future patches) we can compare multiple SVE vectorisation approaches against each other. I'll apply if the prerequisites are approved. 2019-11-05 Richard Sandif

  1   2   >