Re: [PATCH] [RFC]Support vectorization for Complex type.

2022-07-10 Thread Jeff Law via Gcc-patches
On 7/10/2022 9:43 PM, liuhongt via Gcc-patches wrote: The patch only handles load/store(including ctor/permutation, except gather/scatter) for complex type, other operations don't needs to be handled since they will be lowered by pass cplxlower.(MASK_LOAD is not supported for complex type, so

[PATCH] [RFC]Support vectorization for Complex type.

2022-07-10 Thread liuhongt via Gcc-patches
The patch only handles load/store(including ctor/permutation, except gather/scatter) for complex type, other operations don't needs to be handled since they will be lowered by pass cplxlower.(MASK_LOAD is not supported for complex type, so no need to handle either). Instead of support vector(2)

Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818]

2022-07-10 Thread Kewen.Lin via Gcc-patches
on 2022/6/15 14:20, Kewen.Lin wrote: > Hi Honza, > > Thanks for the comments! Some replies are inlined below. > > on 2022/6/14 19:37, Jan Hubicka wrote: >>> Hi, >>> >>> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO >>> if func->decl is not null but no cgraph node is available

Re: [PATCH] inline: Rebuild target option node for caller [PR105459]

2022-07-10 Thread Kewen.Lin via Gcc-patches
on 2022/7/8 19:37, Martin Liška wrote: > On 6/6/22 08:20, Kewen.Lin wrote: >> |Hi, PR105459 exposes one issue in inline_call handling that when it decides >> to copy FP flags from callee to caller and rebuild the optimization node for >> caller fndecl, it's possible that the target option node

Re: [PATCH] middle-end/104854: Avoid overread warning for strnlen and strndup

2022-07-10 Thread Siddhesh Poyarekar
On 10/07/2022 21:44, Jeff Law wrote: This may all argue that these warnings don't belong in -Wall, which is obviously a distinct, but vitally important discussion.  I've always believed that we can make an educated guess about whether or not to include any given warning in -Wall, but we have

Re: [PATCH v2] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

2022-07-10 Thread HAO CHEN GUI via Gcc-patches
Hi, Segher On 8/7/2022 上午 1:31, Segher Boessenkool wrote: >> --- a/gcc/testsuite/gcc.target/powerpc/rlwimi-2.c >> +++ b/gcc/testsuite/gcc.target/powerpc/rlwimi-2.c >> @@ -2,14 +2,14 @@ >> /* { dg-options "-O2" } */ >> >> /* { dg-final { scan-assembler-times {(?n)^\s+[a-z]} 14121 { target ilp32

[PATCH] Allocate general register(memory/immediate) for 16/32/64-bit vector bit_op patterns.

2022-07-10 Thread liuhongt via Gcc-patches
And split it to GPR-version instruction after reload. This will enable below optimization for 16/32/64-bit vector bit_op - movd(%rdi), %xmm0 - movd(%rsi), %xmm1 - pand%xmm1, %xmm0 - movd%xmm0, (%rdi) + movl(%rsi), %eax + andl%eax,

Re: [x86_64 PATCH] Improved Scalar-To-Vector (STV) support for TImode to V1TImode.

2022-07-10 Thread H.J. Lu via Gcc-patches
On Sun, Jul 10, 2022 at 2:38 PM Roger Sayle wrote: > > > Hi HJ, > > I believe this should now be handled by the post-reload (CSE) pass. > Consider the simple test case: > > __int128 a, b, c; > void foo() > { > a = 0; > b = 0; > c = 0; > } > > Without any STV, i.e. -O2 -msse4 -mno-stv, GCC

RE: [x86_64 PATCH] Improved Scalar-To-Vector (STV) support for TImode to V1TImode.

2022-07-10 Thread Roger Sayle
Hi HJ, I believe this should now be handled by the post-reload (CSE) pass. Consider the simple test case: __int128 a, b, c; void foo() { a = 0; b = 0; c = 0; } Without any STV, i.e. -O2 -msse4 -mno-stv, GCC get TI mode writes: movq$0, a(%rip) movq$0, a+8(%rip)

Re: [PATCH] c: Fix location for _Pragma tokens [PR97498]

2022-07-10 Thread Lewis Hyatt via Gcc-patches
On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches wrote: > > > > On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote: > > Hello- > > > > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR > > related to the fact that imprecise locations for _Pragma result in > >

Re: [x86_64 PATCH] Improved Scalar-To-Vector (STV) support for TImode to V1TImode.

2022-07-10 Thread H.J. Lu via Gcc-patches
On Sun, Jul 10, 2022 at 11:36 AM Roger Sayle wrote: > > > Hi Uros, > Yes, I agree. I think it makes sense to have a single STV pass (after > combine and before reload). Let's hear what HJ thinks, but I'm > happy to investigate a follow-up patch that unifies the STV passes. > But it'll be easier

RE: [x86_64 PATCH] Improved Scalar-To-Vector (STV) support for TImode to V1TImode.

2022-07-10 Thread Roger Sayle
Hi Uros, Yes, I agree. I think it makes sense to have a single STV pass (after combine and before reload). Let's hear what HJ thinks, but I'm happy to investigate a follow-up patch that unifies the STV passes. But it'll be easier to confirm there are no "code generation" changes if those

[PATCH] Move reload_completed and other rtl.h globals to crtl structure.

2022-07-10 Thread Roger Sayle
This patch builds upon Richard Biener's suggestion of avoiding global variables to track state/identify which passes have already been run. In the early middle-end, the tree-ssa passes use the curr_properties field in cfun to track this. This patch uses a new rtl_pass_progress int field in crtl

Re: [x86_64 PATCH] Improved Scalar-To-Vector (STV) support for TImode to V1TImode.

2022-07-10 Thread Uros Bizjak via Gcc-patches
On Sat, Jul 9, 2022 at 2:17 PM Roger Sayle wrote: > > > This patch upgrades x86_64's scalar-to-vector (STV) pass to more > aggressively transform 128-bit scalar TImode operations into vector > V1TImode operations performed on SSE registers. TImode functionality > already exists in STV, but only

Re: [PATCH] middle-end/104854: Avoid overread warning for strnlen and strndup

2022-07-10 Thread Jeff Law via Gcc-patches
On 7/9/2022 11:27 PM, Siddhesh Poyarekar wrote: On 10/07/2022 08:59, Jeff Law via Gcc-patches wrote: On 3/9/2022 5:39 PM, Siddhesh Poyarekar wrote: The size argument larger than size of SRC for strnlen and strndup is problematic only if SRC is not NULL terminated, which invokes undefined

RE: [PATCH] Add a heuristic for eliminate redundant load and store in inline pass.

2022-07-10 Thread Cui, Lili via Gcc-patches
> -Original Message- > From: Jan Hubicka > This is interesting idea. Basically we want to guess if inlining will > make SRA and or strore->load propagation possible. I think the > solution using INLINE_HINT may be bit too trigger happy, since it is very > common that this happens and

[PATCH] Complete __gnu_debug::basic_string Standard conformity

2022-07-10 Thread François Dumont via Gcc-patches
Here is a first patch to complete __gnu_debug::basic_string Standard conformity. I prefer to submit this before checking for more missing stuff to check that my proposal of having a testsuite_string.h header is ok. I also noticed some problems with _GLIBCXX_DEBUG_PEDANTIC.     libstdc++:

[committed] testsuite: Require int128 for gcc.dg/pr106063.c

2022-07-10 Thread Dimitar Dimitrov
Require effective target int128 for gcc.dg/pr106063.c. Committed as obvious. PR tree-optimization/106063 gcc/testsuite/ChangeLog: * gcc.dg/pr106063.c: Require effective target int128. CC: Tamar Christina Signed-off-by: Dimitar Dimitrov --- gcc/testsuite/gcc.dg/pr106063.c |

[COMMITTED] Cleanups to irange::nonzero bit code.

2022-07-10 Thread Aldy Hernandez via Gcc-patches
In discussions with Andrew we realized varying_p() was returning true for a range of the entire domain with a non-empty nonzero mask. This is confusing as varying_p() should only return true when absolutely no information is available. A nonzero mask that has any cleared bits is extra