[Bug tree-optimization/89809] movzwl is not utilized when uint16_t is loaded with bit-shifts (while memcpy does)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809 Andrew Pinski changed: What|Removed |Added Known to fail||9.4.0 Resolution|--- |DUPLICATE Status|NEW |RESOLVED Known to work||10.1.0 Target Milestone|--- |10.0 --- Comment #4 from Andrew Pinski --- Fixed for GCC 10. Dup of bug 93040. *** This bug has been marked as a duplicate of bug 93040 ***
[Bug tree-optimization/89809] movzwl is not utilized when uint16_t is loaded with bit-shifts (while memcpy does)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809 --- Comment #3 from JunMa --- the stmt generated by fe has some issue, in 004t.original dump file: return = (uint16_t) ((signed short) *p | (signed short) ((int) *(p + 1) << 8)); However, the return stmt should be: return = (uint16_t) (((int)(uint16_t) *p) | ((int)(uint16_t) *(p + 1) << 8)); then gcc will optimize it.
[Bug tree-optimization/89809] movzwl is not utilized when uint16_t is loaded with bit-shifts (while memcpy does)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809
JunMa changed:
What|Removed |Added
CC||JunMa at linux dot alibaba.com
--- Comment #2 from JunMa ---
g++ pr89809.cpp -O3 -fdump-tree-store-merging:
foo (const unsigned char * p)
{
unsigned char _1;
signed short _2;
unsigned char _3;
int _4;
int _5;
signed short _6;
signed short _7;
uint16_t _10;
[local count: 1073741824]:
_1 = *p_9(D);
_2 = (signed short) _1;
_3 = MEM[(const unsigned char *)p_9(D) + 1B];
_4 = (int) _3;
_5 = _4 << 8;
_6 = (signed short) _5;
_7 = _2 | _6;
_10 = (uint16_t) _7;
return _10;
}
looks like gcc generates too many type conversions, this prevents the
optimization.
[Bug tree-optimization/89809] movzwl is not utilized when uint16_t is loaded with bit-shifts (while memcpy does)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89809 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-24 Component|target |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Strange, the bswap pass is supposed to handle 16 bits just as well as 32. The shift is done in type 'int', maybe the mix between int and short confuses it.
