| Message ID | 1440500777-25966-6-git-send-email-alan.lawrence@arm.com |
|---|---|
| State | New |
| Headers | show |
On 08/25/2015 05:06 AM, Alan Lawrence wrote: > I used this as a means of better-testing the previous changes, as it exercises > the constant replacement code a whole lot more. Indeed, quite a few tests are > now optimized away to nothing on AArch64... > > Always pulling in constants, is almost certainly not what we want, but we may > nonetheless want something more aggressive than the usual --param, e.g. for the > ssa-dom-cse-2.c test. Thoughts welcomed? I'm of the opinion that we have too many knobs already. So I'd perhaps ask whether or not this option is likely to be useful to end users? As for the patch itself, any thoughts on reasonable heuristics for when to pull in the constants? Clearly we don't want the patch as-is, but are there cases we can identify when we want to be more aggressive? jeff
On Tue, Aug 25, 2015 at 9:54 PM, Jeff Law <law@redhat.com> wrote: > On 08/25/2015 05:06 AM, Alan Lawrence wrote: >> >> I used this as a means of better-testing the previous changes, as it >> exercises >> the constant replacement code a whole lot more. Indeed, quite a few tests >> are >> now optimized away to nothing on AArch64... >> >> Always pulling in constants, is almost certainly not what we want, but we >> may >> nonetheless want something more aggressive than the usual --param, e.g. >> for the >> ssa-dom-cse-2.c test. Thoughts welcomed? > > I'm of the opinion that we have too many knobs already. So I'd perhaps ask > whether or not this option is likely to be useful to end users? > > As for the patch itself, any thoughts on reasonable heuristics for when to > pull in the constants? Clearly we don't want the patch as-is, but are there > cases we can identify when we want to be more aggressive? Well - I still think that we need to enhance those followup passes to directly handle the constant pool entry. Expanding the assignment piecewise for arbitrary large initializers is certainly a no-go. IIRC I enhanced FRE to do this at some point. For DOM it's much harder due to the way it is structured and I'd like to keep DOM simple. Note that we still want SRA to partly scalarize the initializer if only few elements remain accessed (so we can optimize the initializer away). Of course that requires catching most followup optimization opportunities before the 2nd SRA run. Richard. > jeff > >
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c index b13d583..370b785 100644 --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c @@ -1,5 +1,5 @@ /* { dg-do compile } */ -/* { dg-options "-O3 -fno-tree-fre -fno-tree-pre -fdump-tree-optimized --param sra-max-scalarization-size-Ospeed=32" } */ +/* { dg-options "-O3 -fno-tree-fre -fno-tree-pre -fdump-tree-optimized" } */ int foo () diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c index a3ff2df..2a741b8 100644 --- a/gcc/tree-sra.c +++ b/gcc/tree-sra.c @@ -2651,7 +2651,8 @@ analyze_all_variable_accesses (void) && scalarizable_type_p (TREE_TYPE (var))) { if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var))) - <= max_scalarization_size) + <= max_scalarization_size + || DECL_IN_CONSTANT_POOL (var)) { create_total_scalarization_access (var); completely_scalarize (var, TREE_TYPE (var), 0, var);