Re: [RFC 5/5] Always completely replace constant pool entries
On Tue, Aug 25, 2015 at 9:54 PM, Jeff Law 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 > >
Re: [RFC 5/5] Always completely replace constant pool entries
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
[RFC 5/5] Always completely replace constant pool entries
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?
Thanks, Alan
gcc/ChangeLog:
* tree-sra.c (analyze_all_variable_accesses): Bypass size limit for
constant-pool accesses.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: Remove --param
sra-max-scalarization-size-Ospeed.
---
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c | 2 +-
gcc/tree-sra.c| 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
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);
--
1.8.3
