Re: [PATCH][testuite] Fix pr80481.C after epilogue vectorization

2020-03-05 Thread Jeff Law
On Thu, 2019-10-31 at 13:55 +, Andre Vieira (lists) wrote: > Hi, > > I used to have this testcase in my patch when testing but forgot to > include it in the patch I sent upstream. This testcase checks that a > vmovaps isn't generated when vectorizing the loop. When I turn epilogue >

Re: [PATCH][testuite] Fix pr80481.C after epilogue vectorization

2019-10-31 Thread Jakub Jelinek
On Thu, Oct 31, 2019 at 06:02:02PM +, Andre Vieira (lists) wrote: > When I debug the vect_analyze_loop calls loop->simdlen is 0 everywhere, with > or without epilogue vectorization turned on. However, I also noticed that > excluding -fopenmp and -fopenmp-simd will yield the generation of

Re: [PATCH][testuite] Fix pr80481.C after epilogue vectorization

2019-10-31 Thread Andre Vieira (lists)
On 31/10/2019 14:04, Jakub Jelinek wrote: On Thu, Oct 31, 2019 at 01:55:26PM +, Andre Vieira (lists) wrote: I used to have this testcase in my patch when testing but forgot to include it in the patch I sent upstream. This testcase checks that a vmovaps isn't generated when vectorizing the

Re: [PATCH][testuite] Fix pr80481.C after epilogue vectorization

2019-10-31 Thread Jakub Jelinek
On Thu, Oct 31, 2019 at 01:55:26PM +, Andre Vieira (lists) wrote: > I used to have this testcase in my patch when testing but forgot to include > it in the patch I sent upstream. This testcase checks that a vmovaps isn't > generated when vectorizing the loop. When I turn epilogue

[PATCH][testuite] Fix pr80481.C after epilogue vectorization

2019-10-31 Thread Andre Vieira (lists)
Hi, I used to have this testcase in my patch when testing but forgot to include it in the patch I sent upstream. This testcase checks that a vmovaps isn't generated when vectorizing the loop. When I turn epilogue vectorization it seems to come back. @Jakub: This test has -fopenmp but I

patch to fix PR80481

2018-01-12 Thread Vladimir Makarov
  The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481    During forming an allocation thread in a multi-region function a conflict allocno was added to the thread and that resulted in generation of additional moves.  The patch prevents inclusion of conflict allocnos