Re: [RFC PATCH] fold one element {mem{set,cpy,pcpy,move},b{zero,copy}} (PR middle-end/27567)

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Aug 31, 2006 at 06:04:37AM -0600, Roger Sayle wrote:
> This is OK for mainline, provided its been boostrapped and regression
> tested somewhere, as PR middle-end/27567 is a P2 regression affecting
> all open branches.  However, as it's a bit intrusive, and I'm cautious
> of corner cases or potential interactions on STRICT_ALIGNMENT targets,
> let's leave it a week or two on mainline to confirm there are no problems
> before backporting to 4.1 and 4.0.

While it seemed to generate correct code even for unaligned
memcpy/memset/etc. arguments, at least on STRICT_ALIGNMENT arches the
generated code was different after the patch, but not always better
and even for !STRICT_ALIGNMENT arches I'm not 100% sure if direct
assignment is always what would be used by
emit_block_move/clear_storage.  So at least for now I'd prefer to only
do this for aligned memory and keep unaligned memcpy/memset/...
until RTL expansion.  Are you ok with that change?

> If you could spin this patch on your build farm, the wide number of
> architectures covered would go a long way to easing my concerns.

The attached 4.2 patch was bootstrapped/regtested on i686-linux and
regtested on x86_64-linux, the 4.1 patch (which is except for whitespace
identical) has been bootstrapped/regtested on
{i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux.

	Jakub

Attachment: gcc42-pr27567.patch
Description: Text document

Attachment: gcc41-pr27567.patch
Description: Text document