[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2006-04-26 07:58 ---
Ok, that makes sense.  Still the failure mode is weird and hints at the
vectorizer not following those semantics but something else.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2006-04-25 11:49 ---
Confirmed.  We generate

0x08048475 main+193:  movdqu (%edx),%xmm0
0x08048479 main+197:  movdqa %xmm0,(%eax)

but both %edx and %eax are unaligned:

eax0x804a021134520865
ecx0x0  0
edx0x804a009134520841

4.0.3 works, because nothing is vectorized there.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.1.0
  Known to work||4.0.3
   Last reconfirmed|-00-00 00:00:00 |2006-04-25 11:49:33
   date||
Summary|gcc 4.1 produces bad code - |[4.1 Regression] vectorizer
   |ftree-vectorize option  |generates aligned accesses
   ||to unaligned memory


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2006-04-25 11:55 ---
mainline doesn't do vectorization here:

/tmp/t.c:12: note: === vect_analyze_dependences ===
/tmp/t.c:12: note: not vectorized: can't determine dependence between *src.1_24
and *dest.0_23
/tmp/t.c:12: note: bad data dependence. 

while 4.1 peels for alignment (wrongly).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2006-04-25 14:23 
---
Richard, you confirmed this.

But to me this looks like the code is violating the aliasing rules
(which would mean that the PR in invalid):
*(uint64_t *)dest = *(uint64_t *)src;
but
uint8_t *dest
const uint8_t *src


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org, reichelt at gcc dot gnu
   ||dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2006-04-25 14:27 ---
Yes, but the problem appears with -O1 which has -fno-strict-aliasing.  Now
whether -fno-strict-aliasing makes the testcase valid is another question ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2006-04-25 14:29 ---
Changing the function to take both arguments as uint8_t* fixes the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299

[Bug tree-optimization/27299] [4.1 Regression] vectorizer generates aligned accesses to unaligned memory

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-04-25 17:35 ---
(In reply to comment #5)
 Yes, but the problem appears with -O1 which has -fno-strict-aliasing.  Now
 whether -fno-strict-aliasing makes the testcase valid is another question ;)

Nope, unaligned access is different from strict aliasing. With the cast to
uint64_t* you say the alignment is correct for that type.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27299