This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


Attachment: gcc42-pr27567.patch
Description: Text document

Attachment: gcc41-pr27567.patch
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]