Bug 68417 - [6 Regression] Missed vectorization opportunity when setting struct field
Summary: [6 Regression] Missed vectorization opportunity when setting struct field
Status: CLOSED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 6.0
: P1 normal
Target Milestone: 6.0
Assignee: vekumar
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2015-11-18 15:56 UTC by Alexander Fomin
Modified: 2015-12-14 11:40 UTC (History)
2 users (show)

See Also:
Host:
Target: i686-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-11-20 00:00:00


Attachments
A reproducer (186 bytes, text/plain)
2015-11-18 15:56 UTC, Alexander Fomin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Fomin 2015-11-18 15:56:45 UTC
Created attachment 36763 [details]
A reproducer

A loop in the test attached compiled with -m32 -msse4.2 -O2 -ftree-vectorize is no more vectorized after r230454(while on r223524.
Comment 1 Alexander Fomin 2015-11-18 16:10:39 UTC
I'm sorry for the typo above.
Vectorization is OK for r230453, but we miss if-conversion since r230434.
Comment 2 Alexander Fomin 2015-11-18 16:14:47 UTC
Sorry once again - looks like smth is also wrong with me today :)
I'm talking about r230454 and r230453 of course.
Comment 3 Richard Biener 2015-11-20 09:35:40 UTC
Confirmed.
Comment 4 vekumar 2015-12-09 10:20:07 UTC
Older trunk showed (gcc version 6.0.0 20151202 (experimental) (GCC))
iftmp.1_19 = p1_36->y;
tree could trap...

Today's trunk (gcc version 6.0.0 20151209)
Applying if-conversion
new phi replacement stmt
iftmp.1_6 = m1_16 >= m2_18 ? iftmp.1_19 : iftmp.1_20;
Removing basic block 4
basic block 4, loop depth 1
Comment 5 vekumar 2015-12-09 11:13:09 UTC
Richard,

STMT: m1 = p1->x - m;

While hashing p1->x being a component ref,  we are hashing operand 0 part 
ie TREE_OPERAND (ref, 0). This is unconditionally read and written.

STMT: p3->y = (m1 >= m2) ? p1->y : p2->y;
Now for p1->y master DR is what we hashed previously for p1->x since p1->y is alos a component ref. 

Fix for PR 68583
https://gcc.gnu.org/viewcvs?rev=231444&root=gcc&view=rev

Checks if candidate DR is unconditional accessed outside and also is a read only.

 /* If a is unconditionally accessed then ... */
  if (DR_RW_UNCONDITIONALLY (*master_dr))
    {
      /* an unconditional read won't trap.  */
      if (DR_IS_READ (a))
        return true;

This holds true now and hence does if conversion.

Since this is expected can we close this PR as fixed?
Comment 6 Richard Biener 2015-12-09 12:29:34 UTC
Fixed.
Comment 7 Richard Biener 2015-12-09 12:29:51 UTC
Author: rguenth
Date: Wed Dec  9 12:29:19 2015
New Revision: 231452

URL: https://gcc.gnu.org/viewcvs?rev=231452&root=gcc&view=rev
Log:
2015-12-09  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/68417
	* gcc.dg/vect/pr68417.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/vect/pr68417.c
Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 8 Alexander Fomin 2015-12-14 11:40:49 UTC
Thanks!