[Bug tree-optimization/83195] [8 regression] pr82929.c scan for "Merging successful" fail
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Nov 28 15:33:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83195
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is because arm is cheating:
proc check_effective_target_non_strict_align {} {
# On ARM, the default is to use STRICT_ALIGNMENT, but there
# are interfaces defined for misaligned access and thus
# depending on the architecture levels unaligned access is
# available.
if [istarget "arm*-*-*"] {
return [check_effective_target_arm_unaligned]
}
return [check_no_compiler_messages non_strict_align assembly {
char *y;
typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
c *z;
void foo(void) { z = (c *) y; }
} "-Wcast-align"]
}
proc check_effective_target_store_merge { } {
if { [is-effective-target non_strict_align ] && [is-effective-target
int32plus] } {
return 1
}
return 0
}
The testcase really cares about:
bool allow_unaligned_store
= !STRICT_ALIGNMENT && PARAM_VALUE (PARAM_STORE_MERGING_ALLOW_UNALIGNED);
bool allow_unaligned_load = allow_unaligned_store;
If that is not true, then in this case the optimization is not beneficial.
Is this the only store merging testcase that fails on arm?
I'd prefer not to add __builtin_assume_aligned and similar to the testcase so
that it tests the !STRICT_ALIGNMENT behavior (perhaps we can have another one
with that builtin), so do I need to uglify by using { target { store_merge && {
! arm*-*-* } } } ?
More information about the Gcc-bugs
mailing list