RE: Inline memcpy in GCC 4.1.1

2006-06-07 Thread Jon Beniston 
 
 In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote:
 
  So, two questions: any idea why 4.1.1 is no longer able to 
  automatically inline memcpys and why is the source operand for 
  movmemsi not know to be as widely aligned as it actually is?
 
 See PR middle-end/27226
 

Thanks a lot, that patch fixed it.

Cheers,
Jon

Inline memcpy in GCC 4.1.1

2006-06-06 Thread Jon Beniston 
Hi,

I'm updating a port from 3.4.6 to 4.1.1. In 3.4.6, I hadn't implemented
movmemsi patterns, but the compiler could still inline memcpy's (and also
strcpys where source string is a const) by itself. After updating to 4.1.1,
calls to memcpy are always generated. 

I've had a bash at implementing movmemsi, but in a test case that does a
strcpy (dest, const), it appears the 4th parameter (alignment) is always
1, and doing a MEM_ALIGN on the source operand results in 8, despite the
fact I have implemented the CONSTANT_ALIGNMENT and DATA_ALIGNMENT macros to
ensure that STRING_CSTs and QImode ARRAY_TYPEs get implemented on a
BITS_PER_WORD boundary (If I look at the assembler output, then that shows
the string being aligned as expected on a word boundary). 

So, two questions: any idea why 4.1.1 is no longer able to automatically
inline memcpys and why is the source operand for movmemsi not know to be as
widely aligned as it actually is?

Cheers,
Jon

Re: Inline memcpy in GCC 4.1.1

2006-06-06 Thread Joern RENNECKE 

In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote:


So, two questions: any idea why 4.1.1 is no longer able to automatically
inline memcpys and why is the source operand for movmemsi not know to be as
widely aligned as it actually is?


See PR middle-end/27226