Bug 53535 - non-aligned memset on non-strict-alignment targets not optimized where aligned memset is
non-aligned memset on non-strict-alignment targets not optimized where aligne...
Status: UNCONFIRMED
Product: gcc
Classification: Unclassified
Component: middle-end
4.8.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: missed-optimization
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-31 04:28 UTC by Hans-Peter Nilsson
Modified: 2012-06-07 20:44 UTC (History)
0 users

See Also:
Host:
Target: x86_64-linux
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Modified gcc.dg/pr46647.c (935 bytes, text/plain)
2012-05-31 04:30 UTC, Hans-Peter Nilsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Peter Nilsson 2012-05-31 04:28:25 UTC
The attached code is a modified gcc.dg/pr46647.c, which shows that memset isn't optimized on unaligned short (int-sized) data as it is for aligned data, even for non-strict-alignment targets, such as cris-* and x86_64-linux. Observe the emitted assembly code, which uses the same instructions for aligned and unaligned code as later optimizations cover up (for both cris-* and x86_64-linux). Hence, I guess this bug isn't really that important when it comes to just the generated code, just an annoying middle-end miss and annoyingly failing test-case.  (Whether the over-alignment-checks misses other optimization opportunities is another issue.)

Background: I stumbled upon this when changing the CRIS port to align global data by default. This made the always-before-failing gcc.dg/pr46647.c pass, for no good reason: alignment of data should not make a difference for emitted code (except for atomic support, WIP for CRIS).

This may be related to PR 52861.
Comment 1 Hans-Peter Nilsson 2012-05-31 04:30:08 UTC
Created attachment 27528 [details]
Modified gcc.dg/pr46647.c
Comment 2 Andrew Pinski 2012-05-31 04:32:00 UTC
>alignment of data should not make a difference for emitted code

Unless the loading of unalignment makes it much slower.  I thinking where two aligned half loads are better than one unaligned word load.  I think there are targets like that.
Comment 3 Hans-Peter Nilsson 2012-05-31 04:37:37 UTC
(In reply to comment #0)
> Observe the
> emitted assembly code, which uses the same instructions for aligned and
> unaligned code

...(compare with the code from gcc.dg/pr46647.c here)...

SVN revision 188039.
Comment 4 Hans-Peter Nilsson 2012-05-31 04:40:12 UTC
(In reply to comment #2)
> Unless the loading of unalignment makes it much slower.

Well, yes, I missed adding !SLOW_UNALIGNED_ACCESS in the title. :)
Comment 5 Hans-Peter Nilsson 2012-05-31 04:43:12 UTC
(In reply to comment #4)
> Well, yes, I missed adding !SLOW_UNALIGNED_ACCESS in the title. :)

Never mind, SLOW_UNALIGNED_ACCESS != 0 is much more severe than the cost of single insns.  Bah.  Maybe this is an issue of missing cost metric.
Comment 6 Hans-Peter Nilsson 2012-06-07 20:44:06 UTC
Author: hp
Date: Thu Jun  7 20:44:01 2012
New Revision: 188317

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188317
Log:
	PR middle-end/53535
	* gcc.dg/pr46647.c: xfail for cris-* and crisv32-*.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr46647.c