[gcc r14-10237] sra: Do not leave work for DSE (that it can sometimes not perform)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:1a6c1c85b7ab1ad4bdf9573fcdc04dcce894ba82

commit r14-10237-g1a6c1c85b7ab1ad4bdf9573fcdc04dcce894ba82
Author: Martin Jambor 
Date:   Thu May 9 16:39:44 2024 +0200

sra: Do not leave work for DSE (that it can sometimes not perform)

When looking again at the g++.dg/tree-ssa/pr109849.C testcase we
discovered that it generates terrible store-to-load forwarding stalls
because SRA was leaving behind aggregate loads but all the stores were
by scalar parts and DSE failed to remove the useless load.  SRA has
all the knowledge to remove the statement even now, so this small
patch makes it do so.

With this patch, the g++.dg/tree-ssa/pr109849.C micro-benchmark runs 9
times faster (on an AMD EPYC 75F3 machine).

gcc/ChangeLog:

2024-04-18  Martin Jambor  

* tree-sra.cc (sra_modify_assign): Remove the original statement
also when dealing with a store to a fully covered aggregate from a
non-candidate.

gcc/testsuite/ChangeLog:

2024-04-23  Martin Jambor  

* g++.dg/tree-ssa/pr109849.C: Also check that the aggeegate store
to cur disappears.
* gcc.dg/tree-ssa/ssa-dse-26.c: Instead of relying on DSE,
check that the unwanted stores were removed at early SRA time.

(cherry picked from commit f6743695b4d2bd4da96e56a19157372f93b800bd)

Diff:
---
 gcc/testsuite/g++.dg/tree-ssa/pr109849.C   |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c |  6 +++---
 gcc/tree-sra.cc| 14 --
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr109849.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
index cd348c0f590..d06dbb10482 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-sra" } */
+/* { dg-options "-O2 -fdump-tree-sra -fdump-tree-optimized" } */
 
 #include 
 typedef unsigned int uint32_t;
@@ -29,3 +29,4 @@ main()
 }
 
 /* { dg-final { scan-tree-dump "Created a replacement for stack offset" "sra"} 
} */
+/* { dg-final { scan-tree-dump-not "cur = MEM" "optimized"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
index 43152de5616..1d01392c595 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-dse1-details -fno-short-enums -fno-tree-fre" 
} */
+/* { dg-options "-O2 -fdump-tree-esra -fno-short-enums -fno-tree-fre" } */
 /* { dg-skip-if "we want a BIT_FIELD_REF from fold_truth_andor" { ! lp64 } } */
 /* { dg-skip-if "temporary variable names are not x and y" { 
mmix-knuth-mmixware } } */
 
@@ -31,5 +31,5 @@ constraint_equal (struct constraint a, struct constraint b)
 && constraint_expr_equal (a.rhs, b.rhs);
 }
 
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 2 "dse1" } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 2 "dse1" } } */
+/* { dg-final { scan-tree-dump-not "x = " "esra" } } */
+/* { dg-final { scan-tree-dump-not "y = " "esra" } } */
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 32fa28911f2..8040b0c5645 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -4854,8 +4854,18 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
 But use the RHS aggregate to load from to expose more
 optimization opportunities.  */
  if (access_has_children_p (lacc))
-   generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
-0, 0, gsi, true, true, loc);
+   {
+ generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
+  0, 0, gsi, true, true, loc);
+ if (lacc->grp_covered)
+   {
+ unlink_stmt_vdef (stmt);
+ gsi_remove (& orig_gsi, true);
+ release_defs (stmt);
+ sra_stats.deleted++;
+ return SRA_AM_REMOVED;
+   }
+   }
}
 
   return SRA_AM_NONE;

[gcc r13-8785] testsuite: Adjust pr113359-2_*.c with unsigned long long [PR114662]

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:c827f46d8652d7a089e614302a4cffb6b192284d

commit r13-8785-gc827f46d8652d7a089e614302a4cffb6b192284d
Author: Kewen Lin 
Date:   Wed Apr 10 02:59:43 2024 -0500

testsuite: Adjust pr113359-2_*.c with unsigned long long [PR114662]

pr113359-2_*.c define a struct having unsigned long type
members ay and az which have 4 bytes size at -m32, while
the related constants CL1 and CL2 used for equality check
are always 8 bytes, it makes compiler consider the below

  69   if (a.ay != CL1)
  70 __builtin_abort ();

always to abort and optimize away the following call to
getb, which leads to the expected wpa dumping on
"Semantic equality" missing.

This patch is to modify the types with unsigned long long
accordingly.

PR testsuite/114662

gcc/testsuite/ChangeLog:

* gcc.dg/lto/pr113359-2_0.c: Use unsigned long long instead of
unsigned long.
* gcc.dg/lto/pr113359-2_1.c: Likewise.

(cherry picked from commit 4923ed49b93352bcf9e43cafac38345e4a54c3f8)

Diff:
---
 gcc/testsuite/gcc.dg/lto/pr113359-2_0.c | 8 
 gcc/testsuite/gcc.dg/lto/pr113359-2_1.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/lto/pr113359-2_0.c 
b/gcc/testsuite/gcc.dg/lto/pr113359-2_0.c
index 8b2d5bdfab2..8495667599d 100644
--- a/gcc/testsuite/gcc.dg/lto/pr113359-2_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr113359-2_0.c
@@ -8,15 +8,15 @@
 struct SA
 {
   unsigned int ax;
-  unsigned long ay;
-  unsigned long az;
+  unsigned long long ay;
+  unsigned long long az;
 };
 
 struct SB
 {
   unsigned int bx;
-  unsigned long by;
-  unsigned long bz;
+  unsigned long long by;
+  unsigned long long bz;
 };
 
 struct ZA
diff --git a/gcc/testsuite/gcc.dg/lto/pr113359-2_1.c 
b/gcc/testsuite/gcc.dg/lto/pr113359-2_1.c
index 61bc0547981..8320f347efe 100644
--- a/gcc/testsuite/gcc.dg/lto/pr113359-2_1.c
+++ b/gcc/testsuite/gcc.dg/lto/pr113359-2_1.c
@@ -5,15 +5,15 @@
 struct SA
 {
   unsigned int ax;
-  unsigned long ay;
-  unsigned long az;
+  unsigned long long ay;
+  unsigned long long az;
 };
 
 struct SB
 {
   unsigned int bx;
-  unsigned long by;
-  unsigned long bz;
+  unsigned long long by;
+  unsigned long long bz;
 };
 
 struct ZA

[gcc r12-10443] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:2183e5b5aa3a080624cb95a06993e34dedd09cb2

commit r12-10443-g2183e5b5aa3a080624cb95a06993e34dedd09cb2
Author: Martin Jambor 
Date:   Mon Apr 8 17:34:33 2024 +0200

ipa: Self-DCE of uses of removed call LHSs (PR 108007)

PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.

I have already fixed this for unused parameters in callees, this bug
shows that almost the same thing can happen for removed returns, on
the side of callers.  This means that the issue has to be fixed
elsewhere, in call redirection.  This patch adds a function which
looks for (and through, using a work-list) uses of operations fed
specific SSA names and removes them all.

That would have been easy if it wasn't for debug statements during
tree-inline (from which call redirection is also invoked).  Debug
statements are decoupled from the rest at this point and iterating
over uses of SSAs does not bring them up.  During tree-inline they are
handled especially at the end, I assume in order to make sure that
relative ordering of UIDs are the same with and without debug info.

This means that during tree-inline we need to make a hash of killed
SSAs, that we already have in copy_body_data, available to the
function making the purging.  So the patch duly does also that, making
the interface slightly ugly.  Moreover, all newly unused SSA names
need to be freed and as PR 112616 showed, it must be done in a defined
order, which is what newly added ipa_release_ssas_in_hash does.

This backport to gcc-13 also contains
54e505d0446f86b7ad383acbb8e5501f20872b64 in order not to reintroduce
PR 113757.

gcc/ChangeLog:

2024-04-05  Martin Jambor  

PR ipa/108007
PR ipa/112616
* cgraph.h (cgraph_edge): Add a parameter to
redirect_call_stmt_to_callee.
* ipa-param-manipulation.h (ipa_param_adjustments): Add a
parameter to modify_call.
(ipa_release_ssas_in_hash): Declare.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
parameter killed_ssas, pass it to padjs->modify_call.
* ipa-param-manipulation.cc (purge_all_uses): New function.
(ipa_param_adjustments::modify_call): New parameter killed_ssas.
Instead of substituting uses, invoke purge_all_uses.  If
hash of killed SSAs has not been provided, create a temporary one
and release SSAs that have been added to it.
(compare_ssa_versions): New function.
(ipa_release_ssas_in_hash): Likewise.
* tree-inline.cc (redirect_all_calls): Create
id->killed_new_ssa_names earlier, pass it to edge redirection,
adjust a comment.
(copy_body): Release SSAs in id->killed_new_ssa_names.

gcc/testsuite/ChangeLog:

2024-01-15  Martin Jambor  

PR ipa/108007
PR ipa/112616
* gcc.dg/ipa/pr108007.c: New test.
* gcc.dg/ipa/pr112616.c: Likewise.

(cherry picked from commit 40ddc0b05a47f999b24f20c1becb79004995731b)

Diff:
---
 gcc/cgraph.cc   |  10 +++-
 gcc/cgraph.h|   9 ++-
 gcc/ipa-param-manipulation.cc   | 112 +---
 gcc/ipa-param-manipulation.h|   5 +-
 gcc/testsuite/g++.dg/ipa/pr113757.C |  14 +
 gcc/testsuite/gcc.dg/ipa/pr108007.c |  32 +++
 gcc/testsuite/gcc.dg/ipa/pr112616.c |  28 +
 gcc/tree-inline.cc  |  27 -
 8 files changed, 193 insertions(+), 44 deletions(-)

diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
index 3734c85db637..b5cfa3b36c57 100644
--- a/gcc/cgraph.cc
+++ b/gcc/cgraph.cc
@@ -1403,11 +1403,17 @@ cgraph_edge::redirect_callee (cgraph_node *n)
speculative indirect call, remove "speculative" of the indirect call and
also redirect stmt to it's final direct target.
 
+   When called from within tree-inline, KILLED_SSAs has to contain the pointer
+   to killed_new_ssa_names within the copy_body_data structure and SSAs
+   discovered to be useless (if LHS is removed) will be added to it, otherwise
+   it needs to be NULL.
+
It is up to caller to iteratively transform each "speculative"
direct call as appropriate.  */
 
 gimple *
-cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
+cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e,
+  hash_set  *killed_ssas)
 {
   tree decl = gimple_call_fndecl (e->call_stmt);
   gcall *new_stmt;
@@ -1528,7 +1534,7 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
 

[gcc r12-10442] ipa: Force args obtined through pass-through maps to the expected type (PR 114247)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:44191982c6bd41db1c9d126ea2f15febec3c1f81

commit r12-10442-g44191982c6bd41db1c9d126ea2f15febec3c1f81
Author: Martin Jambor 
Date:   Tue May 14 14:13:36 2024 +0200

ipa: Force args obtined through pass-through maps to the expected type (PR 
114247)

Interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid.  PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these union parameters are split with IPA-SRA.  The
leaf function however uses a signed short member of the union.

In the calling function, we get the unsigned constant as the
replacement for the union and it is then passed in the call without
any type compatibility checks.  Apparently on riscv64 it matters
whether the parameter is signed or unsigned short and so the leaf
function can see different values.

Fixed by using useless_type_conversion_p at the appropriate place and
if it fails, use force_value_to type as elsewhere in similar
situations.

gcc/ChangeLog:

2024-04-04  Martin Jambor  

PR ipa/114247
* ipa-param-manipulation.cc (ipa_param_adjustments::modify_call):
Force values obtined through pass-through maps to the expected
split type.

gcc/testsuite/ChangeLog:

2024-04-04  Patrick O'Neill  
Martin Jambor  

PR ipa/114247
* gcc.dg/ipa/pr114247.c: New test.

(cherry picked from commit 8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe)

Diff:
---
 gcc/ipa-param-manipulation.cc   |  6 ++
 gcc/testsuite/gcc.dg/ipa/pr114247.c | 31 +++
 2 files changed, 37 insertions(+)

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 38328c3e8d0a..3472ef13bc2f 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -719,6 +719,12 @@ ipa_param_adjustments::modify_call (cgraph_edge *cs,
  }
   if (repl)
{
+ if (!useless_type_conversion_p(apm->type, repl->typed.type))
+   {
+ repl = force_value_to_type (apm->type, repl);
+ repl = force_gimple_operand_gsi (, repl,
+  true, NULL, true, GSI_SAME_STMT);
+   }
  vargs.quick_push (repl);
  continue;
}
diff --git a/gcc/testsuite/gcc.dg/ipa/pr114247.c 
b/gcc/testsuite/gcc.dg/ipa/pr114247.c
new file mode 100644
index ..60aa2bc0122f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr114247.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsigned-char -fno-strict-aliasing -fwrapv" } */
+
+union a {
+  unsigned short b;
+  int c;
+  signed short d;
+};
+int e, f = 1, g;
+long h;
+const int **i;
+void j(union a k, int l, unsigned m) {
+  const int *a[100];
+  i = [0];
+  h = k.d;
+}
+static int o(union a k) {
+  k.d = -1;
+  while (1)
+if (f)
+  break;
+  j(k, g, e);
+  return 0;
+}
+int main() {
+  union a n = {1};
+  o(n);
+  if (h != -1)
+__builtin_abort();
+  return 0;
+}

[commited, gcc13] ipa: Compare jump functions in ICF (PR 113907)

[Martin Jambor]

Hi,

This is a manual backport of r14-9840-g1162861439fd3c from master.
Manual because the bits and value range representation in jump
functions have changes during the gcc 14 development cycle.

In PR 113907 comment #58, Honza found a case where ICF thinks bodies
of functions are equivalent but becaise of difference in aliases in a
memory access, different aggregate jump functions are associated with
supposedly equivalent call statements.  This patch adds a way to
compare jump functions and plugs it into ICF to avoid the issue.

Bootstrapped and tested on x86_64-linux.  Committed to the gcc-13
branch.

Martin


gcc/ChangeLog:

2024-05-14  Martin Jambor  

PR ipa/113907
* ipa-prop.h (ipa_jump_functions_equivalent_p): Declare.
(values_equal_for_ipcp_p): Likewise.
* ipa-prop.cc (ipa_agg_pass_through_jf_equivalent_p): New function.
(ipa_agg_jump_functions_equivalent_p): Likewise.
(ipa_jump_functions_equivalent_p): Likewise.
* ipa-cp.cc (values_equal_for_ipcp_p): Make function public.
* ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h, sreal.h,
ipa-cp.h and ipa-prop.h.
(func_checker::compare_gimple_call): Comapre jump functions.

gcc/testsuite/ChangeLog:

2024-05-10  Martin Jambor  

PR ipa/113907
* gcc.dg/lto/pr113907_0.c: New.
* gcc.dg/lto/pr113907_1.c: Likewise.
* gcc.dg/lto/pr113907_2.c: Likewise.
---
 gcc/ipa-cp.cc |   2 +-
 gcc/ipa-icf-gimple.cc |  29 +
 gcc/ipa-prop.cc   | 157 ++
 gcc/ipa-prop.h|   3 +
 gcc/testsuite/gcc.dg/lto/pr113907_0.c |  18 +++
 gcc/testsuite/gcc.dg/lto/pr113907_1.c |  35 ++
 gcc/testsuite/gcc.dg/lto/pr113907_2.c |  11 ++
 7 files changed, 254 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113907_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113907_1.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113907_2.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index b3e0f62e400..8f36608cf33 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -458,7 +458,7 @@ ipcp_lattice::is_single_const ()
 
 /* Return true iff X and Y should be considered equal values by IPA-CP.  */
 
-static bool
+bool
 values_equal_for_ipcp_p (tree x, tree y)
 {
   gcc_checking_assert (x != NULL_TREE && y != NULL_TREE);
diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 49302ad56c6..054a557bd58 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -42,7 +42,11 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-sra.h"
 
 #include "tree-ssa-alias-compare.h"
+#include "alloc-pool.h"
+#include "symbol-summary.h"
 #include "ipa-icf-gimple.h"
+#include "sreal.h"
+#include "ipa-prop.h"
 
 namespace ipa_icf_gimple {
 
@@ -751,6 +755,31 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)
   && !compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2)))
 return return_false_with_msg ("GIMPLE internal call LHS type mismatch");
 
+  if (!gimple_call_internal_p (s1))
+{
+  cgraph_edge *e1 = cgraph_node::get (m_source_func_decl)->get_edge (s1);
+  cgraph_edge *e2 = cgraph_node::get (m_target_func_decl)->get_edge (s2);
+  class ipa_edge_args *args1 = ipa_edge_args_sum->get (e1);
+  class ipa_edge_args *args2 = ipa_edge_args_sum->get (e2);
+  if ((args1 != nullptr) != (args2 != nullptr))
+   return return_false_with_msg ("ipa_edge_args mismatch");
+  if (args1)
+   {
+ int n1 = ipa_get_cs_argument_count (args1);
+ int n2 = ipa_get_cs_argument_count (args2);
+ if (n1 != n2)
+   return return_false_with_msg ("ipa_edge_args nargs mismatch");
+ for (int i = 0; i < n1; i++)
+   {
+ struct ipa_jump_func *jf1 = ipa_get_ith_jump_func (args1, i);
+ struct ipa_jump_func *jf2 = ipa_get_ith_jump_func (args2, i);
+ if (((jf1 != nullptr) != (jf2 != nullptr))
+ || (jf1 && !ipa_jump_functions_equivalent_p (jf1, jf2)))
+   return return_false_with_msg ("jump function mismatch");
+   }
+   }
+}
+
   return compare_operand (t1, t2, get_operand_access_type (, t1));
 }
 
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 0d816749534..11ba2521b2c 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -6022,5 +6022,162 @@ ipcp_transform_function (struct cgraph_node *node)
   return modified_mem_access ? TODO_update_ssa_only_virtuals : 0;
 }
 
+/* Return true if the two pass_through components of two jump functions are
+   known to be equivalent.  AGG_JF denotes whether they are part of aggregate
+   functions or not.  The function can be used before the IPA phase of IPA-CP
+   or inlining because it c

[gcc r13-8774] ipa: Compare jump functions in ICF (PR 113907)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:1db45e83021a8a87f41e22053910fcce6e8e2c2c

commit r13-8774-g1db45e83021a8a87f41e22053910fcce6e8e2c2c
Author: Martin Jambor 
Date:   Tue May 14 17:01:21 2024 +0200

ipa: Compare jump functions in ICF (PR 113907)

This is a manual backport of r14-9840-g1162861439fd3c from master.
Manual because the bits and value range representation in jump
functions have changes during the gcc 14 development cycle.

In PR 113907 comment #58, Honza found a case where ICF thinks bodies
of functions are equivalent but becaise of difference in aliases in a
memory access, different aggregate jump functions are associated with
supposedly equivalent call statements.  This patch adds a way to
compare jump functions and plugs it into ICF to avoid the issue.

gcc/ChangeLog:

2024-05-14  Martin Jambor  

PR ipa/113907
* ipa-prop.h (ipa_jump_functions_equivalent_p): Declare.
(values_equal_for_ipcp_p): Likewise.
* ipa-prop.cc (ipa_agg_pass_through_jf_equivalent_p): New function.
(ipa_agg_jump_functions_equivalent_p): Likewise.
(ipa_jump_functions_equivalent_p): Likewise.
* ipa-cp.cc (values_equal_for_ipcp_p): Make function public.
* ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h, 
sreal.h,
ipa-cp.h and ipa-prop.h.
(func_checker::compare_gimple_call): Comapre jump functions.

gcc/testsuite/ChangeLog:

2024-05-10  Martin Jambor  

PR ipa/113907
* gcc.dg/lto/pr113907_0.c: New.
* gcc.dg/lto/pr113907_1.c: Likewise.
* gcc.dg/lto/pr113907_2.c: Likewise.

Diff:
---
 gcc/ipa-cp.cc |   2 +-
 gcc/ipa-icf-gimple.cc |  29 +++
 gcc/ipa-prop.cc   | 157 ++
 gcc/ipa-prop.h|   3 +
 gcc/testsuite/gcc.dg/lto/pr113907_0.c |  18 
 gcc/testsuite/gcc.dg/lto/pr113907_1.c |  35 
 gcc/testsuite/gcc.dg/lto/pr113907_2.c |  11 +++
 7 files changed, 254 insertions(+), 1 deletion(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index b3e0f62e4003..8f36608cf33b 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -458,7 +458,7 @@ ipcp_lattice::is_single_const ()
 
 /* Return true iff X and Y should be considered equal values by IPA-CP.  */
 
-static bool
+bool
 values_equal_for_ipcp_p (tree x, tree y)
 {
   gcc_checking_assert (x != NULL_TREE && y != NULL_TREE);
diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 49302ad56c65..054a557bd588 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -42,7 +42,11 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-sra.h"
 
 #include "tree-ssa-alias-compare.h"
+#include "alloc-pool.h"
+#include "symbol-summary.h"
 #include "ipa-icf-gimple.h"
+#include "sreal.h"
+#include "ipa-prop.h"
 
 namespace ipa_icf_gimple {
 
@@ -751,6 +755,31 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)
   && !compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2)))
 return return_false_with_msg ("GIMPLE internal call LHS type mismatch");
 
+  if (!gimple_call_internal_p (s1))
+{
+  cgraph_edge *e1 = cgraph_node::get (m_source_func_decl)->get_edge (s1);
+  cgraph_edge *e2 = cgraph_node::get (m_target_func_decl)->get_edge (s2);
+  class ipa_edge_args *args1 = ipa_edge_args_sum->get (e1);
+  class ipa_edge_args *args2 = ipa_edge_args_sum->get (e2);
+  if ((args1 != nullptr) != (args2 != nullptr))
+   return return_false_with_msg ("ipa_edge_args mismatch");
+  if (args1)
+   {
+ int n1 = ipa_get_cs_argument_count (args1);
+ int n2 = ipa_get_cs_argument_count (args2);
+ if (n1 != n2)
+   return return_false_with_msg ("ipa_edge_args nargs mismatch");
+ for (int i = 0; i < n1; i++)
+   {
+ struct ipa_jump_func *jf1 = ipa_get_ith_jump_func (args1, i);
+ struct ipa_jump_func *jf2 = ipa_get_ith_jump_func (args2, i);
+ if (((jf1 != nullptr) != (jf2 != nullptr))
+ || (jf1 && !ipa_jump_functions_equivalent_p (jf1, jf2)))
+   return return_false_with_msg ("jump function mismatch");
+   }
+   }
+}
+
   return compare_operand (t1, t2, get_operand_access_type (, t1));
 }
 
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 0d8167495341..11ba2521b2c9 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -6022,5 +6022,162 @@ ipcp_transform_function (struct cgraph_node *node)
   return modified_mem_access ? TODO_update_ssa_only_virtuals : 0;
 }
 
+/* Return true if the two pass_through components of two jump functions are
+   known to be equivalent.  AGG_JF denotes whether they are part of

[gcc r13-8773] ICF: Make ICF and SRA agree on padding

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:10bf53a80eefa46500bffb442719777e2640e7d7

commit r13-8773-g10bf53a80eefa46500bffb442719777e2640e7d7
Author: Martin Jambor 
Date:   Mon Apr 8 18:53:23 2024 +0200

ICF: Make ICF and SRA agree on padding

PR 113359 shows that (at least with -fno-strict-aliasing) ICF can
unify two functions which copy an aggregate type of the same size but
then SRA, through its total scalarization, can copy the aggregate by
pieces, skipping paddding, but the padding was not the same in the two
original functions that ICF unified.

This patch enhances SRA with the ability to collect padding
information which then can be compared from within ICF.  Unfortunately
SRA uses OPTION_SET_P when determining its limits, so ICF needs to
switch cfuns at least once to figure it out too.

gcc/ChangeLog:

2024-03-27  Martin Jambor  

PR ipa/113359
* ipa-icf-gimple.h (func_checker): New members
safe_for_total_scalarization_p, m_total_scalarization_limit_known_p
and m_total_scalarization_limit.
(func_checker::func_checker): Initialize new member variables.
* ipa-icf-gimple.cc: Include tree-sra.h.
(func_checker::func_checker): Initialize new member variables.
(func_checker::safe_for_total_scalarization_p): New function.
(func_checker::compare_operand): Use the new function.
* tree-sra.h (sra_get_max_scalarization_size): Declare.
(sra_total_scalarization_would_copy_same_data_p): Likewise.
* tree-sra.cc (prepare_iteration_over_array_elts): New function.
(class sra_padding_collecting): New.
(sra_padding_collecting::record_padding): Likewise.
(scalarizable_type_p): Rename to totally_scalarizable_type_p.  Add
ability to record padding when requested.
(totally_scalarize_subtree): Split out gathering information 
necessary
to iterate over array elements to prepare_iteration_over_array_elts.
Fix errornous early exit.
(analyze_all_variable_accesses): Adjust the call to
totally_scalarizable_type_p.  Move determining of total scalariation
size limit...
(sra_get_max_scalarization_size): ...here.
(check_ts_and_push_padding_to_vec): New function.
(sra_total_scalarization_would_copy_same_data_p): Likewise.

gcc/testsuite/ChangeLog:

2024-03-27  Martin Jambor  

PR ipa/113359
* gcc.dg/lto/pr113359-1_0.c: New.
* gcc.dg/lto/pr113359-1_1.c: Likewise.
* gcc.dg/lto/pr113359-2_0.c: Likewise.
* gcc.dg/lto/pr113359-2_1.c: Likewise.
* gcc.dg/lto/pr113359-3_0.c: Likewise.
* gcc.dg/lto/pr113359-3_1.c: Likewise.
* gcc.dg/lto/pr113359-4_0.c: Likewise.
* gcc.dg/lto/pr113359-4_1.c: Likewise.
* gcc.dg/lto/pr113359-5_0.c: Likewise.
* gcc.dg/lto/pr113359-5_1.c: Likewise.

(cherry picked from commit 1e3312a25a7b34d6e3f549273e1674c7114e4408)

Diff:
---
 gcc/ipa-icf-gimple.cc   |  41 +-
 gcc/ipa-icf-gimple.h|  15 +-
 gcc/testsuite/gcc.dg/lto/pr113359-1_0.c |  86 +++
 gcc/testsuite/gcc.dg/lto/pr113359-1_1.c |  38 +
 gcc/testsuite/gcc.dg/lto/pr113359-2_0.c |  87 +++
 gcc/testsuite/gcc.dg/lto/pr113359-2_1.c |  38 +
 gcc/testsuite/gcc.dg/lto/pr113359-3_0.c | 114 +++
 gcc/testsuite/gcc.dg/lto/pr113359-3_1.c |  49 +++
 gcc/testsuite/gcc.dg/lto/pr113359-4_0.c | 114 +++
 gcc/testsuite/gcc.dg/lto/pr113359-4_1.c |  49 +++
 gcc/testsuite/gcc.dg/lto/pr113359-5_0.c | 118 +++
 gcc/testsuite/gcc.dg/lto/pr113359-5_1.c |  50 +++
 gcc/tree-sra.cc | 252 +---
 gcc/tree-sra.h  |   3 +
 14 files changed, 999 insertions(+), 55 deletions(-)

diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index f4180c0fa813..49302ad56c65 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgloop.h"
 #include "attribs.h"
 #include "gimple-walk.h"
+#include "tree-sra.h"
 
 #include "tree-ssa-alias-compare.h"
 #include "ipa-icf-gimple.h"
@@ -59,7 +60,8 @@ func_checker::func_checker (tree source_func_decl, tree 
target_func_decl,
   : m_source_func_decl (source_func_decl), m_target_func_decl 
(target_func_decl),
 m_ignored_source_nodes (ignored_source_nodes),
 m_ignored_target_nodes (ignored_target_nodes),
-m_ignore_labels (ignore_labels), m_tbaa (tbaa)
+m_ignore_labels (ignore_labels), m_tbaa (tbaa),
+m_total_scalarization_limit_known_p (false)
 {
   function *source_func = DECL_STRUCT_FUNCTION (source_func_decl);
   fu

[gcc r15-346] sra: Do not leave work for DSE (that it can sometimes not perform)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:f6743695b4d2bd4da96e56a19157372f93b800bd

commit r15-346-gf6743695b4d2bd4da96e56a19157372f93b800bd
Author: Martin Jambor 
Date:   Thu May 9 16:39:44 2024 +0200

sra: Do not leave work for DSE (that it can sometimes not perform)

When looking again at the g++.dg/tree-ssa/pr109849.C testcase we
discovered that it generates terrible store-to-load forwarding stalls
because SRA was leaving behind aggregate loads but all the stores were
by scalar parts and DSE failed to remove the useless load.  SRA has
all the knowledge to remove the statement even now, so this small
patch makes it do so.

With this patch, the g++.dg/tree-ssa/pr109849.C micro-benchmark runs 9
times faster (on an AMD EPYC 75F3 machine).

gcc/ChangeLog:

2024-04-18  Martin Jambor  

* tree-sra.cc (sra_modify_assign): Remove the original statement
also when dealing with a store to a fully covered aggregate from a
non-candidate.

gcc/testsuite/ChangeLog:

2024-04-23  Martin Jambor  

* g++.dg/tree-ssa/pr109849.C: Also check that the aggeegate store
to cur disappears.
* gcc.dg/tree-ssa/ssa-dse-26.c: Instead of relying on DSE,
check that the unwanted stores were removed at early SRA time.

Diff:
---
 gcc/testsuite/g++.dg/tree-ssa/pr109849.C   |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c |  6 +++---
 gcc/tree-sra.cc| 14 --
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr109849.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
index cd348c0f5906..d06dbb104829 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-sra" } */
+/* { dg-options "-O2 -fdump-tree-sra -fdump-tree-optimized" } */
 
 #include 
 typedef unsigned int uint32_t;
@@ -29,3 +29,4 @@ main()
 }
 
 /* { dg-final { scan-tree-dump "Created a replacement for stack offset" "sra"} 
} */
+/* { dg-final { scan-tree-dump-not "cur = MEM" "optimized"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
index 43152de56163..1d01392c5957 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-dse1-details -fno-short-enums -fno-tree-fre" 
} */
+/* { dg-options "-O2 -fdump-tree-esra -fno-short-enums -fno-tree-fre" } */
 /* { dg-skip-if "we want a BIT_FIELD_REF from fold_truth_andor" { ! lp64 } } */
 /* { dg-skip-if "temporary variable names are not x and y" { 
mmix-knuth-mmixware } } */
 
@@ -31,5 +31,5 @@ constraint_equal (struct constraint a, struct constraint b)
 && constraint_expr_equal (a.rhs, b.rhs);
 }
 
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 2 "dse1" } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 2 "dse1" } } */
+/* { dg-final { scan-tree-dump-not "x = " "esra" } } */
+/* { dg-final { scan-tree-dump-not "y = " "esra" } } */
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 32fa28911f2d..8040b0c56451 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -4854,8 +4854,18 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
 But use the RHS aggregate to load from to expose more
 optimization opportunities.  */
  if (access_has_children_p (lacc))
-   generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
-0, 0, gsi, true, true, loc);
+   {
+ generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
+  0, 0, gsi, true, true, loc);
+ if (lacc->grp_covered)
+   {
+ unlink_stmt_vdef (stmt);
+ gsi_remove (& orig_gsi, true);
+ release_defs (stmt);
+ sra_stats.deleted++;
+ return SRA_AM_REMOVED;
+   }
+   }
}
 
   return SRA_AM_NONE;

[PATCH] sra: Do not leave work for DSE (that it can sometimes not perform)

[Martin Jambor]

Hi,

when looking again at the g++.dg/tree-ssa/pr109849.C testcase we
discovered that it generates terrible store-to-load forwarding stalls
because SRA was leaving behind aggregate loads but all the stores were
by scalar parts and DSE failed to remove the useless load.  SRA has
all the knowledge to remove the statement even now, so this small
patch makes it do so.

With this patch, the g++.dg/tree-ssa/pr109849.C micro-benchmark runs 9
times faster (on an AMD EPYC 75F3 machine).

Bootstrapped and tested on x86_64.  OK for master?

Given that the patch is simple but can sometimes have large benefit,
could it possibly be backported to gcc-14 branch even if it is not a
regression (at least not in the last decade) in a few weeks?

Thanks,

Martin


gcc/ChangeLog:

2024-04-18  Martin Jambor  

* tree-sra.cc (sra_modify_assign): Remove the original statement
also when dealing with a store to a fully covered aggregate from a
non-candidate.

gcc/testsuite/ChangeLog:

2024-04-23  Martin Jambor  

* g++.dg/tree-ssa/pr109849.C: Also check that the aggeegate store
to cur disappears.
* gcc.dg/tree-ssa/ssa-dse-26.c: Instead of relying on DSE,
check that the unwanted stores were removed at early SRA time.
---
 gcc/testsuite/g++.dg/tree-ssa/pr109849.C   |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c |  6 +++---
 gcc/tree-sra.cc| 14 --
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr109849.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
index cd348c0f590..d06dbb10482 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr109849.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-sra" } */
+/* { dg-options "-O2 -fdump-tree-sra -fdump-tree-optimized" } */
 
 #include 
 typedef unsigned int uint32_t;
@@ -29,3 +29,4 @@ main()
 }
 
 /* { dg-final { scan-tree-dump "Created a replacement for stack offset" "sra"} 
} */
+/* { dg-final { scan-tree-dump-not "cur = MEM" "optimized"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
index 43152de5616..1d01392c595 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-dse1-details -fno-short-enums -fno-tree-fre" 
} */
+/* { dg-options "-O2 -fdump-tree-esra -fno-short-enums -fno-tree-fre" } */
 /* { dg-skip-if "we want a BIT_FIELD_REF from fold_truth_andor" { ! lp64 } } */
 /* { dg-skip-if "temporary variable names are not x and y" { 
mmix-knuth-mmixware } } */
 
@@ -31,5 +31,5 @@ constraint_equal (struct constraint a, struct constraint b)
 && constraint_expr_equal (a.rhs, b.rhs);
 }
 
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 2 "dse1" } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 2 "dse1" } } */
+/* { dg-final { scan-tree-dump-not "x = " "esra" } } */
+/* { dg-final { scan-tree-dump-not "y = " "esra" } } */
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 32fa28911f2..8040b0c5645 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -4854,8 +4854,18 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator 
*gsi)
 But use the RHS aggregate to load from to expose more
 optimization opportunities.  */
  if (access_has_children_p (lacc))
-   generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
-0, 0, gsi, true, true, loc);
+   {
+ generate_subtree_copies (lacc->first_child, rhs, lacc->offset,
+  0, 0, gsi, true, true, loc);
+ if (lacc->grp_covered)
+   {
+ unlink_stmt_vdef (stmt);
+ gsi_remove (& orig_gsi, true);
+ release_defs (stmt);
+ sra_stats.deleted++;
+ return SRA_AM_REMOVED;
+   }
+   }
}
 
   return SRA_AM_NONE;
-- 
2.44.0

Welcome 2024 GCC GSoC 2024 participants!

[Martin Jambor]

Hello,

I am pleased to announce that we will have as many as seven
contributors working on GCC as part of their Google Summer of Code
(GSoC) projects in 2024!  In no particular order:

- Anuj Mohite will be enhancing the f951 compiler's DO CONCURRENT
  construct while mentored by Tobias Burnus and Thomas Schwinge.

- Georgii Burunsuzian will be implementing OpenMP and OpenACC
  offloading to a separate process on the same host, also mentored by
  Thomas Schwinge and Tobias Burnus.

- Jasmine Tang will work on inline assembly support in our Rust
  front-end, mentors of this project will be Arthur Cohen and
  Pierre-Emmanuel Patry.

- Kushal Pal will focus on borrow-checking IR location support this
  summer, also in our Rust front-end.  Likewise, the project will be
  lead by Arthur Cohen and Pierre-Emmanuel Patry.

- Muhammad Mahad will work on the Rust front-end too, specifically on
  rustc testsuite adapter for GCCRS.  In addition to Arthur Cohen and
  Pierre-Emmanuel Patry his third mentor will also be Thomas Schwinge.

- Pranil Dey will be improving nothrow detection in GCC, which is a
  project mentored by Jan Hubička and to a lesser extent by myself.

- Thor Preimesberger has successfully applied to the program with a
  project to implement structured Dumping of GENERIC Trees.  The
  effort will be mentored by Richard Biener.

I'd like to congratulate all of them for putting together truly solid
proposals and wish them best of luck with their projects.

The GSoC program has now entered its "community bonding period" which
lasts until May 27th.  During this time, contributors should get in
touch with their mentors unless they have already done so and probably
start looking quite a bit more at GCC in general.

In the initial discussion with your mentors, please take a while to
talk about the time-frame of your project.  If you are happy with the
standard 12 week duration (mid-term evaluation deadline on July 12th,
final deadline on August 26th) you do not need to do anything.  The
program can however also accommodate non-standard schedules, see the
options at:
https://developers.google.com/open-source/gsoc/help/project-dates

If you want to change the duration of your project, first please reach
an agreement with your mentor and then email me and/or other GSoC
Org-admins.  The change can be done at any point in the program as
long as you are not asking to extend an evaluation which has already
started.  In the case of the standard schedule this means that an
Org-admin has to enter the change before July 8 to affect the mid-term
evaluation and before August 19th to affect the final evaluation.

I'd also like to ask all seven accepted contributors to take a few
minutes to familiarize themselves with the legal pre-requisites that
we have for contributing.  There are two options.  The simpler one is
that copyright remains with you but you provide a "Developer
Certificate of Origin" for your contributions.  You can do that by
adding a "Signed-off-by:" tag to all your patches.  The second option
is to assign your copyright to the Free Software Foundation - if
anyone wants to do this, please let me know and I will help.  More
information about both is at:
https://gcc.gnu.org/contribute.html#legal

Because GCC targets many computer platforms, you may also find it very
useful to get an account on the compile farm so that you can test your
code on a variety of architectures.  For more details, see
https://gcc.gnu.org/wiki/CompileFarm

Last but not least, feel free to raise any question you may have on an
appropriate mailing list (https://gcc.gnu.org/lists.html) or say hi to
us on the gcc development IRC channel
(https://gcc.gnu.org/wiki/GCConIRC).

If you have any concerns or questions regarding the organizational part
of GSoC 2024 or just don't know who else to reach out to, feel free to
contact me throughout the duration of the program.

Once more, congratulations and good luck!

Martin

gcc-wwwdocs branch master updated. d63b0ce2968ddaa335a679ba4595ca582ef76d6d

[Martin Jambor via Gcc-cvs-wwwdocs]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  d63b0ce2968ddaa335a679ba4595ca582ef76d6d (commit)
  from  d2323d3efa30008ed05519a398eb7fe1e9b446d3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit d63b0ce2968ddaa335a679ba4595ca582ef76d6d
Author: Martin Jambor 
Date:   Fri May 3 11:53:43 2024 +0200

List znver5 in the GCC 14 changes document

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8dfbf7dc..46a0266d 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -954,6 +954,12 @@ __asm (".global __flmap_lock"  "\n\t"
 -fsanitize=hwaddress will enable -mlam=u57
 by default.
   
+   GCC now supports AMD CPUs based on the znver5 core via
+-march=znver5.  In addition to the ISA extensions
+enabled on a znver4 core, this switch further enables the
+AVX512VP2INTERSECT, AVXVNNI, MOVDIR64B, MOVDIRI, and PREFETCHI ISA
+extensions.
+  
 
 
 MCore

---

Summary of changes:
 htdocs/gcc-14/changes.html | 6 ++
 1 file changed, 6 insertions(+)


hooks/post-receive
-- 
gcc-wwwdocs

Re: [wwwdocs] Add znver5 to GCC 14 changes

[Martin Jambor]

Hi Gerald,

On Fri, May 03 2024, Gerald Pfeifer wrote:
> Hi Martin,
>
> On Thu, 2 May 2024, Martin Jambor wrote:
>> +   GCC now supports AMD CPUs based on the znver5 core via
>> +-march=znver5.  Based on ISA extensions enabled on
>> +a znver4 core, the switch further enables the AVXVNNI, MOVDIRI,
>> +MOVDIR64B, AVX512VP2INTERSECT, and PREFETCHI ISA extensions.
>
> just two small suggestions: We usually sort extensions alphabetically,
> so  AVX512VP2INTERSECT, AVXVNNI, MOVDIR64B, MOVDIRI, and PREFETCHI. If 
> there is a specific reason to do otherwise, that's okay of course.
>
> And I might write "In addition to the ISA extensions enabled on a znver4 
> core, this switch..." to avoid the repetition of "based on" (and make it a 
> bit more clear even that it is a full superset, not just 'loosely' based".
>

Thanks for the suggestions, I'll go ahead and commit the following then.

Martin


diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8dfbf7dc..46a0266d 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -954,6 +954,12 @@ __asm (".global __flmap_lock"  "\n\t"
 -fsanitize=hwaddress will enable -mlam=u57
 by default.
   
+   GCC now supports AMD CPUs based on the znver5 core via
+-march=znver5.  In addition to the ISA extensions
+enabled on a znver4 core, this switch further enables the
+AVX512VP2INTERSECT, AVXVNNI, MOVDIR64B, MOVDIRI, and PREFETCHI ISA
+extensions.
+  
 
 
 MCore

[wwwdocs] Add znver5 to GCC 14 changes

[Martin Jambor]

Hello,

based on input from AMD, I'd like to commit the following to the wwwdocs
repo to point out new support for Zen 5 based AMD CPUs in GCC 14?

Is it OK?  Any suggestions, comments or questions?

Thanks,

Martin



diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8dfbf7dc..d250340b 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -954,6 +954,11 @@ __asm (".global __flmap_lock"  "\n\t"
 -fsanitize=hwaddress will enable -mlam=u57
 by default.
   
+   GCC now supports AMD CPUs based on the znver5 core via
+-march=znver5.  Based on ISA extensions enabled on
+a znver4 core, the switch further enables the AVXVNNI, MOVDIRI,
+MOVDIR64B, AVX512VP2INTERSECT, and PREFETCHI ISA extensions.
+  
 
 
 MCore

gcc-wwwdocs branch master updated. d2323d3efa30008ed05519a398eb7fe1e9b446d3

[Martin Jambor via Gcc-cvs-wwwdocs]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  d2323d3efa30008ed05519a398eb7fe1e9b446d3 (commit)
  from  6c84b7b936a085c13e1f33f2028317fe31bbbcd8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit d2323d3efa30008ed05519a398eb7fe1e9b446d3
Author: Martin Jambor 
Date:   Thu May 2 23:40:22 2024 +0200

Describe gcc target pragma changes in gcc-14/porting_to.html

Adding a subsection on how gcc target pragma changed in GCC 14 in the
corresponding porting-to document.

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index c825a68e..a20d82c2 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -514,6 +514,48 @@ be included explicitly when compiling with GCC 14:
 
 
 
+Pragma GCC target now affects preprocessor symbols
+
+
+The behavior of pragma GCC target and specifically how it affects ISA
+macros has changed in GCC 14.  In GCC 13 and older, the GCC
+target pragma defined and undefined corresponding ISA macros in
+C when using the integrated preprocessor during compilation but not
+when the preprocessor was invoked as a separate step or when using
+the -save-temps option.  In C++ the ISA macro definitions
+were performed in a way which did not have any actual effect.
+
+In GCC 14 C++ behaves like C with integrated preprocessing in earlier
+versions. Moreover, in both languages ISA macros are defined and
+undefined as expected when preprocessing separately from compilation.
+
+
+This can lead to different behavior, especially in C++.  For example,
+a part of the C++ snippet below will be (silently) compiled for an
+incorrect instruction set by GCC 14.
+
+
+  #if ! __AVX2__
+  #pragma GCC push_options
+  #pragma GCC target("avx2")
+  #endif
+
+  /* Code to be compiled for AVX2. */
+
+  /* With GCC 14, __AVX2__ here will always be defined and pop_options
+  never invoked. */
+  #if ! __AVX2__
+  #pragma GCC pop_options
+  #endif
+
+  /* With GCC 14, all following functions will be compiled for AVX2
+  which was not intended. */
+
+
+
+The fix in this case is to remember whether pop_options
+needs to be performed in a new user-defined macro.
+
 
 
 

---

Summary of changes:
 htdocs/gcc-14/porting_to.html | 42 ++
 1 file changed, 42 insertions(+)


hooks/post-receive
-- 
gcc-wwwdocs

Re: [wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior

[Martin Jambor]

Hi,

On Wed, May 01 2024, Gerald Pfeifer wrote:
> On Tue, 30 Apr 2024, Martin Jambor wrote:
>> +Pragma GCC Target now affects preprocessor 
>> symbols
>
> Note the id: should be "gcc-target-pragma", though I even suggest to 
> simplify and say "target-pragma".
>
>> +The behavior of pragma GCC Target and specifically how it affects ISA
>
> Seconding Jakub's
>  
>   "And here as well, perhaps even #pragma GCC target."
>
>> +macros has changed in GCC 14.  In GCC 13 and older, the GCC
>> +target pragma defined and undefined corresponding ISA macros in
>> +C when using integrated preprocessor during compilation but not when
>
> "...the integrated preprocessor..."
>
>> +preprocessor was invoked as a separate step or when using -save-temps.
>
> "...the preprocessor..."
>
> and -save-temps, or better "the -save-temps 
> option".
>
>> +This can lead to different behavior, especially in C++.  For example,
>> +functions the C++ snippet below will be (silently) compiled for an
>> +incorrect instruction set by GCC 14.
>
> "functions" above looks like it's extraneous and should be skipped?
>
>> +  /* With GCC 14, __AVX2__ here will always be defined and pop_options
>> +  never called. */
>> +  #if ! __AVX2__
>> +  #pragma GCC pop_options
>> +  #endif
>
> Maybe a bit subtle, I would not say a #pragma is called; how about invoked 
> or activated?
>
>> +
>> +The fix in this case would be to remember
>> +whether pop_options needs to be performed in a new
>> +user-defined macro.
>
> "The fix in this case is to remember" (or "...remembering...")
>

Thanks for your suggestions, this is what I am going to commit in a
moment.

Martin


diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index c825a68e..a20d82c2 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -514,6 +514,48 @@ be included explicitly when compiling with GCC 14:
 
 
 
+Pragma GCC target now affects preprocessor symbols
+
+
+The behavior of pragma GCC target and specifically how it affects ISA
+macros has changed in GCC 14.  In GCC 13 and older, the GCC
+target pragma defined and undefined corresponding ISA macros in
+C when using the integrated preprocessor during compilation but not
+when the preprocessor was invoked as a separate step or when using
+the -save-temps option.  In C++ the ISA macro definitions
+were performed in a way which did not have any actual effect.
+
+In GCC 14 C++ behaves like C with integrated preprocessing in earlier
+versions. Moreover, in both languages ISA macros are defined and
+undefined as expected when preprocessing separately from compilation.
+
+
+This can lead to different behavior, especially in C++.  For example,
+a part of the C++ snippet below will be (silently) compiled for an
+incorrect instruction set by GCC 14.
+
+
+  #if ! __AVX2__
+  #pragma GCC push_options
+  #pragma GCC target("avx2")
+  #endif
+
+  /* Code to be compiled for AVX2. */
+
+  /* With GCC 14, __AVX2__ here will always be defined and pop_options
+  never invoked. */
+  #if ! __AVX2__
+  #pragma GCC pop_options
+  #endif
+
+  /* With GCC 14, all following functions will be compiled for AVX2
+  which was not intended. */
+
+
+
+The fix in this case is to remember whether pop_options
+needs to be performed in a new user-defined macro.
+
 
 
 

Re: [wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior

[Martin Jambor]

Hi,

On Thu, Apr 25 2024, Jakub Jelinek wrote:
> On Thu, Apr 25, 2024 at 02:34:22PM +0200, Martin Jambor wrote:
>> when looking at a package build issue with GCC 14, Michal Jireš noted a
>> different behavior of pragma GCC Target.  This snippet tries to describe
>> the gist of the problem.  I have left it in the C section even though it
>> is not really C specific, but could not think of a good name for a new
>> section for it.  Ideas (and any other suggestions for improvements)
>> welcome, of course.
>
> The change was more subtle.
> We used to define/undefine the ISA macros in C in GCC 13 and older as well,
> but only when using integrated preprocessor during compilation,
> so it didn't work that way with -save-temps or separate -E and -S/-c
> steps.
> While in C++ it behaved as if the define/undefines aren't done at all
> (they were done, but after preprocessing/lexing everything, so didn't
> affect anything).
> In GCC 14, it behaves in C++ the same as in C in older versions, and
> additionally they are defined/undefined also when using separate
> preprocessing, in both C and C++.
>

I see, thanks for the correction.

Would the following then perhaps describe the situation accurately?
Note that I have moved the whole thing to C++ section because it seems
porting issues in C because of this are quite unlikely.

Michal, I assume that the file where this issue happened was written in
C++, right?

Martin



diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index c825a68e..1e67b0b3 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -514,6 +514,51 @@ be included explicitly when compiling with GCC 14:
 
 
 
+Pragma GCC Target now affects preprocessor 
symbols
+
+
+The behavior of pragma GCC Target and specifically how it affects ISA
+macros has changed in GCC 14.  In GCC 13 and older, the GCC
+target pragma defined and undefined corresponding ISA macros in
+C when using integrated preprocessor during compilation but not when
+preprocessor was invoked as a separate step or when using -save-temps.
+In C++ the ISA macro definitions were performed in a way which did not
+have any actual effect.
+
+In GCC 14 C++ behaves like C with integrated preprocessing in earlier
+versions. Moreover, in both languages ISA macros are defined and
+undefined as expected when preprocessing separately from compilation.
+
+
+This can lead to different behavior, especially in C++.  For example,
+functions the C++ snippet below will be (silently) compiled for an
+incorrect instruction set by GCC 14.
+
+
+  #if ! __AVX2__
+  #pragma GCC push_options
+  #pragma GCC target("avx2")
+  #endif
+
+  /* Code to be compiled for AVX2. */
+
+  /* With GCC 14, __AVX2__ here will always be defined and pop_options
+  never called. */
+  #if ! __AVX2__
+  #pragma GCC pop_options
+  #endif
+
+  /* With GCC 14, all following functions will be compiled for AVX2
+  which was not intended. */
+
+
+
+The fix in this case would be to remember
+whether pop_options needs to be performed in a new
+user-defined macro.
+
+
+
 
 
 

Re: 1.76% performance loss in VRP due to inlining

[Martin Jambor]

Hi,

On Fri, Apr 26 2024, Aldy Hernandez via Gcc wrote:
> Hi folks!
>
> In implementing prange (pointer ranges), I have found a 1.74% slowdown
> in VRP, even without any code path actually using the code.  I have
> tracked this down to irange::get_bitmask() being compiled differently
> with and without the bare bones patch.  With the patch,
> irange::get_bitmask() has a lot of code inlined into it, particularly
> get_bitmask_from_range() and consequently the wide_int_storage code.
>
> I don't know whether this is expected behavior, and if it is, how to
> mitigate it.  I have tried declaring get_bitmask_from_range() inline,
> but that didn't help.  OTOH, using __attribute__((always_inline))
> helps a bit, but not entirely.  What does help is inlining
> irange::get_bitmask() entirely, but that seems like a big hammer.
>
> The overall slowdown in compilation is 0.26%, because VRP is a
> relatively fast pass, but a measurable pass slowdown is something we'd
> like to avoid.
>
> What's the recommended approach here?

I'm afraid that the right approach (not sure if that also means the
recommended approach) is to figure out why inlining
irange::get_bitmask() helps, i.e. what unnecessary computations or
memory accesses it avoids or which other subsequent optimizations it
enables, etc.  Then we can have a look whether IPA could facilitate this
without inlining (or if eventually code shrinks to a reasonable size,
how to teach the inliner to predict this).

Martin


>
> For the curious, I am attaching before and after copies of
> value-range.s.  I am also attaching the two patches needed to
> reproduce the problem on mainline.  The first patch is merely setup.
> It is the second patch that exhibits the problem.  Notice there are no
> uses of prange yet.
>
> Thanks.
> Aldy
> From ee63833c5f56064ef47c2bb9debd485f77d00171 Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez 
> Date: Tue, 19 Mar 2024 18:04:55 +0100
> Subject: [PATCH] Move get_bitmask_from_range out of irange class.
>
> ---
>  gcc/value-range.cc | 52 +++---
>  gcc/value-range.h  |  1 -
>  2 files changed, 26 insertions(+), 27 deletions(-)
>
> diff --git a/gcc/value-range.cc b/gcc/value-range.cc
> index 70375f7abf9..0f81ce32615 100644
> --- a/gcc/value-range.cc
> +++ b/gcc/value-range.cc
> @@ -31,6 +31,30 @@ along with GCC; see the file COPYING3.  If not see
>  #include "fold-const.h"
>  #include "gimple-range.h"
>  
> +// Return the bitmask inherent in a range.
> +
> +static irange_bitmask
> +get_bitmask_from_range (tree type,
> + const wide_int , const wide_int )
> +{
> +  unsigned prec = TYPE_PRECISION (type);
> +
> +  // All the bits of a singleton are known.
> +  if (min == max)
> +{
> +  wide_int mask = wi::zero (prec);
> +  wide_int value = min;
> +  return irange_bitmask (value, mask);
> +}
> +
> +  wide_int xorv = min ^ max;
> +
> +  if (xorv != 0)
> +xorv = wi::mask (prec - wi::clz (xorv), false, prec);
> +
> +  return irange_bitmask (wi::zero (prec), min | xorv);
> +}
> +
>  void
>  irange::accept (const vrange_visitor ) const
>  {
> @@ -1832,31 +1856,6 @@ irange::invert ()
>  verify_range ();
>  }
>  
> -// Return the bitmask inherent in the range.
> -
> -irange_bitmask
> -irange::get_bitmask_from_range () const
> -{
> -  unsigned prec = TYPE_PRECISION (type ());
> -  wide_int min = lower_bound ();
> -  wide_int max = upper_bound ();
> -
> -  // All the bits of a singleton are known.
> -  if (min == max)
> -{
> -  wide_int mask = wi::zero (prec);
> -  wide_int value = lower_bound ();
> -  return irange_bitmask (value, mask);
> -}
> -
> -  wide_int xorv = min ^ max;
> -
> -  if (xorv != 0)
> -xorv = wi::mask (prec - wi::clz (xorv), false, prec);
> -
> -  return irange_bitmask (wi::zero (prec), min | xorv);
> -}
> -
>  // Remove trailing ranges that this bitmask indicates can't exist.
>  
>  void
> @@ -1978,7 +1977,8 @@ irange::get_bitmask () const
>// in the mask.
>//
>// See also the note in irange_bitmask::intersect.
> -  irange_bitmask bm = get_bitmask_from_range ();
> +  irange_bitmask bm
> += get_bitmask_from_range (type (), lower_bound (), upper_bound ());
>if (!m_bitmask.unknown_p ())
>  bm.intersect (m_bitmask);
>return bm;
> diff --git a/gcc/value-range.h b/gcc/value-range.h
> index 9531df56988..dc5b153a83e 100644
> --- a/gcc/value-range.h
> +++ b/gcc/value-range.h
> @@ -351,7 +351,6 @@ private:
>bool varying_compatible_p () const;
>bool intersect_bitmask (const irange );
>bool union_bitmask (const irange );
> -  irange_bitmask get_bitmask_from_range () const;
>bool set_range_from_bitmask ();
>  
>bool intersect (const wide_int& lb, const wide_int& ub);
> -- 
> 2.44.0
>
> From 03c70de43177a97ec5e9c243aafc798c1f37e6d8 Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez 
> Date: Wed, 20 Mar 2024 06:25:52 +0100
> Subject: [PATCH] Implement minimum prange class exhibiting VRP slowdown.
>
> 

[wwwdocs] Porting-to-14: Mention new pragma GCC Target behavior

[Martin Jambor]

Hello,

when looking at a package build issue with GCC 14, Michal Jireš noted a
different behavior of pragma GCC Target.  This snippet tries to describe
the gist of the problem.  I have left it in the C section even though it
is not really C specific, but could not think of a good name for a new
section for it.  Ideas (and any other suggestions for improvements)
welcome, of course.

Otherwise, would this be good to go to the wwwdocs?

Thanks,

Martin

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index c825a68e..ae9a3cde 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -490,6 +490,43 @@ in C23.
 GCC will probably continue to support old-style function definitions
 even once C23 is used as the default language dialect.
 
+Pragma GCC Target now affects preprocessor 
symbols
+
+
+The behavior of pragma GCC Target has changed in GCC 14.  For example,
+GCC 13 and below defines __AVX2__ only when the target
+is specified on the command line.  This has been considered https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299;>a
+bug and since it was fixed in GCC 14, __AVX2__ is now also
+defined with #pragma GCC target("avx2").
+
+
+Therefore, if macros expand to something like the snippet below,
+functions will be (silently) compiled for an incorrect instruction
+set.
+
+
+  #if ! __AVX2__
+  #pragma GCC push_options
+  #pragma GCC target("avx2")
+  #endif
+
+  /* Code to be compiled for AVX2. */
+
+  /* With GCC 14, __AVX2__ here will always be defined and pop_options
+  never called. */
+  #if ! __AVX2__
+  #pragma GCC pop_options
+  #endif
+
+  /* With GCC 14, all following functions will be compiled for AVX2
+  which was not intended. */
+
+
+
+The fix in this case would be to remember
+whether pop_options needs to be performed in a new
+user-defined macro.
+
 C++ language issues
 
 Header dependency changes

[gcc r13-8620] ipa: Force args obtined through pass-through maps to the expected type (PR 113964)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:5c3238b0d55ec13a2430aa606e2bfed9432e97ac

commit r13-8620-g5c3238b0d55ec13a2430aa606e2bfed9432e97ac
Author: Martin Jambor 
Date:   Fri Apr 19 16:48:12 2024 +0200

ipa: Force args obtined through pass-through maps to the expected type (PR 
113964)

Interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid.  PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these union parameters are split with IPA-SRA.  The
leaf function however uses a signed short member of the union.

In the calling function, we get the unsigned constant as the
replacement for the union and it is then passed in the call without
any type compatibility checks.  Apparently on riscv64 it matters
whether the parameter is signed or unsigned short and so the leaf
function can see different values.

Fixed by using useless_type_conversion_p at the appropriate place and
if it fails, use force_value_to type as elsewhere in similar
situations.

gcc/ChangeLog:

2024-04-04  Martin Jambor  

PR ipa/113964
* ipa-param-manipulation.cc (ipa_param_adjustments::modify_call):
Force values obtined through pass-through maps to the expected
split type.

gcc/testsuite/ChangeLog:

2024-04-04  Patrick O'Neill  
Martin Jambor  

PR ipa/113964
* gcc.dg/ipa/pr114247.c: New test.

(cherry picked from commit 8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe)

Diff:
---
 gcc/ipa-param-manipulation.cc   |  6 ++
 gcc/testsuite/gcc.dg/ipa/pr114247.c | 31 +++
 2 files changed, 37 insertions(+)

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index e4f626ae95e..729d5e8e688 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -738,6 +738,12 @@ ipa_param_adjustments::modify_call (cgraph_edge *cs,
  }
   if (repl)
{
+ if (!useless_type_conversion_p(apm->type, repl->typed.type))
+   {
+ repl = force_value_to_type (apm->type, repl);
+ repl = force_gimple_operand_gsi (, repl,
+  true, NULL, true, GSI_SAME_STMT);
+   }
  vargs.quick_push (repl);
  continue;
}
diff --git a/gcc/testsuite/gcc.dg/ipa/pr114247.c 
b/gcc/testsuite/gcc.dg/ipa/pr114247.c
new file mode 100644
index 000..60aa2bc0122
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr114247.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsigned-char -fno-strict-aliasing -fwrapv" } */
+
+union a {
+  unsigned short b;
+  int c;
+  signed short d;
+};
+int e, f = 1, g;
+long h;
+const int **i;
+void j(union a k, int l, unsigned m) {
+  const int *a[100];
+  i = [0];
+  h = k.d;
+}
+static int o(union a k) {
+  k.d = -1;
+  while (1)
+if (f)
+  break;
+  j(k, g, e);
+  return 0;
+}
+int main() {
+  union a n = {1};
+  o(n);
+  if (h != -1)
+__builtin_abort();
+  return 0;
+}

[gcc r13-8619] ipa: Avoid duplicate replacements in IPA-SRA transformation phase

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:8a3784adf5cd873ca295a5a011d8623338ff3976

commit r13-8619-g8a3784adf5cd873ca295a5a011d8623338ff3976
Author: Martin Jambor 
Date:   Fri Apr 19 16:48:12 2024 +0200

ipa: Avoid duplicate replacements in IPA-SRA transformation phase

When the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the propagation in GIMPLE because that is the last
moment the parameter exists).

However, when IPA-SRA wants to split out a smaller aggregate out
of an aggregate, which happens to be of the same size as a known
scalar constant at the same offset, the transformation bit fails to
recognize the situation, tries to do both splitting and constant
propagation and in PR 111571 testcase creates a nonsensical call
statement on which the call redirection then ICEs.

Fixed by making sure we don't try to do two replacements of the same
part of the same parameter.

The look-up among replacements requires these are sorted and this
patch just sorts them if they are not already sorted before each new
look-up.  The worst number of sortings that can happen is number of
parameters which are both split and have aggregate constants times
param_ipa_max_agg_items (default 16).  I don't think complicating the
source code to optimize for this unlikely case is worth it but if need
be, it can of course be done.

gcc/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::common_initialization): Avoid creating
duplicate replacement entries.

gcc/testsuite/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* gcc.dg/ipa/pr111571.c: New test.

(cherry picked from commit ca56b43105fc09021ec445f1978a17cd85ae5e0c)

Diff:
---
 gcc/ipa-param-manipulation.cc   | 16 
 gcc/testsuite/gcc.dg/ipa/pr111571.c | 29 +
 2 files changed, 45 insertions(+)

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 182f0c6741e..e4f626ae95e 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -1484,6 +1484,22 @@ ipa_param_body_adjustments::common_initialization (tree 
old_fndecl,
 replacement with a constant (for split aggregates passed
 by value).  */
 
+ if (split[parm_num])
+   {
+ /* We must be careful not to add a duplicate
+replacement. */
+ sort_replacements ();
+ ipa_param_body_replacement *pbr
+   = lookup_replacement_1 (m_oparms[parm_num],
+   av.unit_offset);
+ if (pbr)
+   {
+ /* Otherwise IPA-SRA should have bailed out.  */
+ gcc_assert (AGGREGATE_TYPE_P (TREE_TYPE (pbr->repl)));
+ continue;
+   }
+   }
+
  tree repl;
  if (av.by_ref)
repl = av.value;
diff --git a/gcc/testsuite/gcc.dg/ipa/pr111571.c 
b/gcc/testsuite/gcc.dg/ipa/pr111571.c
new file mode 100644
index 000..2a4adc608db
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr111571.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2"  } */
+
+struct a {
+  int b;
+};
+struct c {
+  long d;
+  struct a e;
+  long f;
+};
+int g, h, i;
+int j() {return 0;}
+static void k(struct a l, int p) {
+  if (h)
+g = 0;
+  for (; g; g = j())
+if (l.b)
+  break;
+}
+static void m(struct c l) {
+  k(l.e, l.f);
+  for (;; --i)
+;
+}
+int main() {
+  struct c n = {10, 9};
+  m(n);
+}

RE: Project Selection Process and Timeline for GSoC 2024

[Martin Jambor]

Hello,

On Fri, Apr 05 2024, Vedant5432 via Gcc wrote:
> Hello,
> I am a potential contributor for GSoC 2024, I made a submission for the
> project Extend the Static Analysis Pass, I was wondering about the process
> of ranking the proposals and the general timelines when the applicants will
> be notified if their proposals will be considered potentially?

We are diligently evaluating all GSoC proposals including and will
finish doing so by the deadline set by Google.

Google reserves the right to announce the acceptance themselves - and
they have they final say when they determine the number of slots an
organization receives - therefore we cannot publicly disclose much
details about the evaluation process, I am afraid.

> Would using
> Zulip be the best form of communication for faster responses compared to
> email?

Only for gcc-rust related issues/topics/discussions.

Sorry that we cannot disclose much at this point.

Martin

Re: GSoC "Nothrow detection" proposal review

[Martin Jambor]

Hello,

On Fri, Apr 05 2024, PRANIL DEY wrote:
> Hello GCC Community,
> I am Pranil Dey and I had submitted a proposal for the project "Improve
> nothrow detection in GCC", but as the deadline period was a holiday time I
> wanted to ask you to review my proposal now.
> I am already getting familiar with the code but I wanted some pointers for
> now till selection time so as to read up some more and work more
> efficiently if selected.
> Proposal link -
> https://drive.google.com/file/d/1GynfephYrwaOHG4l7al3dNedrnjL9Dsr/view?usp=drive_link

I can assure you that we are diligently evaluating all GSoC proposals
including yours (I can also confirm I can see your proposal my GSoC Org
Admin dahsboard) and will finish doing so by the deadline set by Google.

Google reserves the right to announce the acceptance themselves - and
they have they final say when they determine the number of slots an
organization receives, therefore we cannot publicly disclose much
details about the evaluation process, I am afraid.

Martin

Re: [PATCH] contrib/check-params-in-docs.py: Ignore target-specific params

[Martin Jambor]

Hi,

On Fri, Apr 12 2024, Filip Kastl wrote:
> On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
>> Hi!
>> 
>> On 2024-04-11T19:52:51+0200, Martin Jambor  wrote:
>> > contrib/check-params-in-docs.py is a script that checks that all
>> > options reported with ./gcc/xgcc -Bgcc --help=param are in
>> > gcc/doc/invoke.texi and vice versa.
>> 
>> Eh, first time I'm hearing about this one!

It's running as part of our internal buildbot that Martin Liška set up.

I must admit I did want to spend the minimum time necessary to fix the
failure and did not realize Filip was looking at it too until I commited
my simple fix...

>> 
>> (a) Shouldn't this be running as part of the GCC build process?
>> 
>> > gcn-preferred-vectorization-factor is in the manual but normally not
>> > reported by --help, probably because I do not have gcn offload
>> > configured.
>> 
>> No, because you've not been building GCC for GCN target.  ;-P
>> 
>> > This patch makes the script silently about this particular
>> > fact.
>> 
>> (b) Shouldn't we instead ignore any '--param's with "gcn" prefix, similar
>> to how that's done for "skip aarch64 params"?
>> 
>> (c) ..., and shouldn't we likewise skip any "x86" ones?
>> 
>> (d) ..., or in fact any target specific ones, following after the generic
>> section?  (Easily achieved with a special marker in
>> 'gcc/doc/invoke.texi', just before:
>> 
>> The following choices of @var{name} are available on AArch64 targets:
>> 
>> ..., and adjusting the 'takewhile' in 'contrib/check-params-in-docs.py'
>> accordingly?
>
> Hi,
>
> I've made a patch to address (b), (c), (d).  I didn't adjust takewhile.  I
> chose to do it differently since target-specific params in both invoke.texi 
> and
> --help=params have to be ignored.
>
> The downside of this patch is that the script won't complain if someone adds a
> target-specific param and doesn't document it.
>
> What do you think?

...and this is clearly much better.  Thanks!

Martin

>
> Cheers,
> Filip
>
> -- 8< --
>
> contrib/check-params-in-docs.py is a script that checks that all options
> reported with gcc --help=params are in gcc/doc/invoke.texi and vice
> versa.
> gcc/doc/invoke.texi lists target-specific params but gcc --help=params
> doesn't.  This meant that the script would mistakenly complain about
> parms missing from --help=params.  Previously, the script was just set
> to ignore aarch64 and gcn params which solved this issue only for x86.
> This patch sets the script to ignore all target-specific params.
>
> contrib/ChangeLog:
>
>   * check-params-in-docs.py: Ignore target specific params.
>
> Signed-off-by: Filip Kastl 
> ---
>  contrib/check-params-in-docs.py | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/contrib/check-params-in-docs.py b/contrib/check-params-in-docs.py
> index f7879dd8e08..ccdb8d72169 100755
> --- a/contrib/check-params-in-docs.py
> +++ b/contrib/check-params-in-docs.py
> @@ -38,6 +38,9 @@ def get_param_tuple(line):
>  description = line[i:].strip()
>  return (name, description)
>  
> +def target_specific(param):
> +return param.split('-')[0] in ('aarch64', 'gcn', 'x86')
> +
>  
>  parser = argparse.ArgumentParser()
>  parser.add_argument('texi_file')
> @@ -45,13 +48,16 @@ parser.add_argument('params_output')
>  
>  args = parser.parse_args()
>  
> -ignored = {'logical-op-non-short-circuit', 
> 'gcn-preferred-vectorization-factor'}
> -params = {}
> +ignored = {'logical-op-non-short-circuit'}
> +help_params = {}
>  
>  for line in open(args.params_output).readlines():
>  if line.startswith(' ' * 2) and not line.startswith(' ' * 8):
>  r = get_param_tuple(line)
> -params[r[0]] = r[1]
> +help_params[r[0]] = r[1]
> +
> +# Skip target-specific params
> +help_params = [x for x in help_params.keys() if not target_specific(x)]
>  
>  # Find section in .texi manual with parameters
>  texi = ([x.strip() for x in open(args.texi_file).readlines()])
> @@ -66,14 +72,13 @@ for line in texi:
>  texi_params.append(line[len(token):])
>  break
>  
> -# skip digits
> +# Skip digits
>  texi_params = [x for x in texi_params if not x[0].isdigit()]
> -# skip aarch64 params
> -texi_params = [x for x in texi_params if not x.startswith('aarch64')]
> -sorted_params = sorted(texi_params)
> +# Skip target-specific params
> +texi_params = [x for x in texi_params if not target_specific(x)]
>  
>  texi_set = set(texi_params) - ignored
> -params_set = set(params.keys()) - ignored
> +params_set = set(help_params) - ignored
>  
>  success = True
>  extra = texi_set - params_set
> -- 
> 2.43.1

[gcc r14-9926] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:33f83d3cd84f9876180a2e2a9d1ea082debdaa37

commit r14-9926-g33f83d3cd84f9876180a2e2a9d1ea082debdaa37
Author: Martin Jambor 
Date:   Thu Apr 11 19:37:45 2024 +0200

contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

contrib/check-params-in-docs.py is a script that checks that all
options reported with ./gcc/xgcc -Bgcc --help=param are in
gcc/doc/invoke.texi and vice versa.
gcn-preferred-vectorization-factor is in the manual but normally not
reported by --help, probably because I do not have gcn offload
configured.  This patch makes the script silently about this particular
fact.

contrib/ChangeLog:

2024-04-11  Martin Jambor  

* check-params-in-docs.py (ignored): Add
gcn-preferred-vectorization-factor.

Diff:
---
 contrib/check-params-in-docs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/check-params-in-docs.py b/contrib/check-params-in-docs.py
index 623c82284e2..f7879dd8e08 100755
--- a/contrib/check-params-in-docs.py
+++ b/contrib/check-params-in-docs.py
@@ -45,7 +45,7 @@ parser.add_argument('params_output')
 
 args = parser.parse_args()
 
-ignored = {'logical-op-non-short-circuit'}
+ignored = {'logical-op-non-short-circuit', 
'gcn-preferred-vectorization-factor'}
 params = {}
 
 for line in open(args.params_output).readlines():

[PATCH] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

[Martin Jambor]

Hi,

contrib/check-params-in-docs.py is a script that checks that all
options reported with ./gcc/xgcc -Bgcc --help=param are in
gcc/doc/invoke.texi and vice versa.
gcn-preferred-vectorization-factor is in the manual but normally not
reported by --help, probably because I do not have gcn offload
configured.  This patch makes the script silently about this particular
fact.

I'll push the patch as obvious momentarily.

Martin


contrib/ChangeLog:

2024-04-11  Martin Jambor  

* check-params-in-docs.py (ignored): Add
gcn-preferred-vectorization-factor.
---
 contrib/check-params-in-docs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/check-params-in-docs.py b/contrib/check-params-in-docs.py
index 623c82284e2..f7879dd8e08 100755
--- a/contrib/check-params-in-docs.py
+++ b/contrib/check-params-in-docs.py
@@ -45,7 +45,7 @@ parser.add_argument('params_output')
 
 args = parser.parse_args()
 
-ignored = {'logical-op-non-short-circuit'}
+ignored = {'logical-op-non-short-circuit', 
'gcn-preferred-vectorization-factor'}
 params = {}
 
 for line in open(args.params_output).readlines():
-- 
2.44.0

gcc-wwwdocs branch master updated. 8d40685d6a2b26aff26f1cd68f5bfd9728b2eda5

[Martin Jambor via Gcc-cvs-wwwdocs]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
   via  8d40685d6a2b26aff26f1cd68f5bfd9728b2eda5 (commit)
  from  408ef50eced845bc5a084bfac868686df74cbdcf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 8d40685d6a2b26aff26f1cd68f5bfd9728b2eda5
Author: Martin Jambor 
Date:   Wed Apr 10 16:33:14 2024 +0200

Fix link to "Feature Test Macros" in "Porting to GCC 14" page

Michal Jireš found out that the link to Feature Test Macros on the
Porting to GCC 14 page was broken, it misses a "/latest/" directory in
the middle of the path.

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 35274691..c825a68e 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -133,7 +133,7 @@ On GNU systems, headers described in standards (such as the 
C
 standard, or POSIX) may require the definition of certain
 macros at the start of the compilation before all required
 function declarations are made available.
-See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature
 Test Macros
+See https://sourceware.org/glibc/manual/latest/html_node/Feature-Test-Macros.html;>Feature
 Test Macros
 in the GNU C Library manual for details.
 
 

---

Summary of changes:
 htdocs/gcc-14/porting_to.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
gcc-wwwdocs

[wwwdocs, committed] Fix link to "Feature Test Macros" in "Porting to GCC 14" page

[Martin Jambor]

Hi,

Michal Jireš found out that the link to Feature Test Macros on the
Porting to GCC 14 page was broken, it misses a "/latest/" directory in
the middle of the path.

I'll commit the following as obvious.

Thanks,

Martin

---
 htdocs/gcc-14/porting_to.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html
index 35274691..c825a68e 100644
--- a/htdocs/gcc-14/porting_to.html
+++ b/htdocs/gcc-14/porting_to.html
@@ -133,7 +133,7 @@ On GNU systems, headers described in standards (such as the 
C
 standard, or POSIX) may require the definition of certain
 macros at the start of the compilation before all required
 function declarations are made available.
-See https://sourceware.org/glibc/manual/html_node/Feature-Test-Macros.html;>Feature
 Test Macros
+See https://sourceware.org/glibc/manual/latest/html_node/Feature-Test-Macros.html;>Feature
 Test Macros
 in the GNU C Library manual for details.
 
 
-- 
2.44.0

Re: [PATCH] ICF: Make ICF and SRA agree on padding

[Martin Jambor]

Hello,

On Sun, Apr 07 2024, Xi Ruoyao wrote:
> On Thu, 2024-04-04 at 23:19 +0200, Martin Jambor wrote:
>> The patch has been approved by Honza in Bugzilla. (I hope.  He did write
>> it looked reasonable.)  Together with the patch for PR 113907, it has
>> passed bootstrap, LTO bootstrap and LTO profiledbootstrap and testing on
>> x86_64-linux and bootstrap and LTO bootstrap on ppc64le-linux.  It also
>> passed normal bootstrap on aarch64-linux but there many testcases failed
>> because the compiler timed out.  The machine is old and slow and might
>> have been oversubscribed so my plan is to try again on gcc185 from
>> cfarm.  If that goes well, I intend to commit the patch and then start
>> working on backports.
>
> I've tried these two patches out on my own 24-core AArch64 machine. 
> Bootstrapped (but no LTO or PGO) and regtested fine.
>

Thank you very much, I have pushed th patches to upstream.

Martin

[gcc r14-9841] ICF: Make ICF and SRA agree on padding

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:1e3312a25a7b34d6e3f549273e1674c7114e4408

commit r14-9841-g1e3312a25a7b34d6e3f549273e1674c7114e4408
Author: Martin Jambor 
Date:   Mon Apr 8 18:53:23 2024 +0200

ICF: Make ICF and SRA agree on padding

PR 113359 shows that (at least with -fno-strict-aliasing) ICF can
unify two functions which copy an aggregate type of the same size but
then SRA, through its total scalarization, can copy the aggregate by
pieces, skipping paddding, but the padding was not the same in the two
original functions that ICF unified.

This patch enhances SRA with the ability to collect padding
information which then can be compared from within ICF.  Unfortunately
SRA uses OPTION_SET_P when determining its limits, so ICF needs to
switch cfuns at least once to figure it out too.

gcc/ChangeLog:

2024-03-27  Martin Jambor  

PR ipa/113359
* ipa-icf-gimple.h (func_checker): New members
safe_for_total_scalarization_p, m_total_scalarization_limit_known_p
and m_total_scalarization_limit.
(func_checker::func_checker): Initialize new member variables.
* ipa-icf-gimple.cc: Include tree-sra.h.
(func_checker::func_checker): Initialize new member variables.
(func_checker::safe_for_total_scalarization_p): New function.
(func_checker::compare_operand): Use the new function.
* tree-sra.h (sra_get_max_scalarization_size): Declare.
(sra_total_scalarization_would_copy_same_data_p): Likewise.
* tree-sra.cc (prepare_iteration_over_array_elts): New function.
(class sra_padding_collecting): New.
(sra_padding_collecting::record_padding): Likewise.
(scalarizable_type_p): Rename to totally_scalarizable_type_p.  Add
ability to record padding when requested.
(totally_scalarize_subtree): Split out gathering information 
necessary
to iterate over array elements to prepare_iteration_over_array_elts.
Fix errornous early exit.
(analyze_all_variable_accesses): Adjust the call to
totally_scalarizable_type_p.  Move determining of total scalariation
size limit...
(sra_get_max_scalarization_size): ...here.
(check_ts_and_push_padding_to_vec): New function.
(sra_total_scalarization_would_copy_same_data_p): Likewise.

gcc/testsuite/ChangeLog:

2024-03-27  Martin Jambor  

PR ipa/113359
* gcc.dg/lto/pr113359-1_0.c: New.
* gcc.dg/lto/pr113359-1_1.c: Likewise.
* gcc.dg/lto/pr113359-2_0.c: Likewise.
* gcc.dg/lto/pr113359-2_1.c: Likewise.
* gcc.dg/lto/pr113359-3_0.c: Likewise.
* gcc.dg/lto/pr113359-3_1.c: Likewise.
* gcc.dg/lto/pr113359-4_0.c: Likewise.
* gcc.dg/lto/pr113359-4_1.c: Likewise.
* gcc.dg/lto/pr113359-5_0.c: Likewise.
* gcc.dg/lto/pr113359-5_1.c: Likewise.

Diff:
---
 gcc/ipa-icf-gimple.cc   |  41 +-
 gcc/ipa-icf-gimple.h|  15 +-
 gcc/testsuite/gcc.dg/lto/pr113359-1_0.c |  86 +++
 gcc/testsuite/gcc.dg/lto/pr113359-1_1.c |  38 +
 gcc/testsuite/gcc.dg/lto/pr113359-2_0.c |  87 +++
 gcc/testsuite/gcc.dg/lto/pr113359-2_1.c |  38 +
 gcc/testsuite/gcc.dg/lto/pr113359-3_0.c | 114 +++
 gcc/testsuite/gcc.dg/lto/pr113359-3_1.c |  49 +++
 gcc/testsuite/gcc.dg/lto/pr113359-4_0.c | 114 +++
 gcc/testsuite/gcc.dg/lto/pr113359-4_1.c |  49 +++
 gcc/testsuite/gcc.dg/lto/pr113359-5_0.c | 118 +++
 gcc/testsuite/gcc.dg/lto/pr113359-5_1.c |  50 +++
 gcc/tree-sra.cc | 252 +---
 gcc/tree-sra.h  |   3 +
 14 files changed, 999 insertions(+), 55 deletions(-)

diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 17f62bec068..c25eb24710f 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgloop.h"
 #include "attribs.h"
 #include "gimple-walk.h"
+#include "tree-sra.h"
 
 #include "tree-ssa-alias-compare.h"
 #include "alloc-pool.h"
@@ -64,7 +65,8 @@ func_checker::func_checker (tree source_func_decl, tree 
target_func_decl,
   : m_source_func_decl (source_func_decl), m_target_func_decl 
(target_func_decl),
 m_ignored_source_nodes (ignored_source_nodes),
 m_ignored_target_nodes (ignored_target_nodes),
-m_ignore_labels (ignore_labels), m_tbaa (tbaa)
+m_ignore_labels (ignore_labels), m_tbaa (tbaa),
+m_total_scalarization_limit_known_p (false)
 {
   function *source_func = DECL_STRUCT_FUNCTION (source_func_decl);
   function *target_func = DECL_STRUCT_FUNCTION (target_func_decl);
@@ -361,6 +363,36 @@ 

[gcc r14-9840] ipa: Compare jump functions in ICF (PR 113907)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:1162861439fd3c4b30fc3ccd49462e47e876f04a

commit r14-9840-g1162861439fd3c4b30fc3ccd49462e47e876f04a
Author: Martin Jambor 
Date:   Mon Apr 8 18:53:23 2024 +0200

ipa: Compare jump functions in ICF (PR 113907)

In PR 113907 comment #58, Honza found a case where ICF thinks bodies
of functions are equivalent but becaise of difference in aliases in a
memory access, different aggregate jump functions are associated with
supposedly equivalent call statements.  This patch adds a way to
compare jump functions and plugs it into ICF to avoid the issue.

gcc/ChangeLog:

2024-03-20  Martin Jambor  

PR ipa/113907
* ipa-prop.h (class ipa_vr): Declare new overload of a member 
function
equal_p.
(ipa_jump_functions_equivalent_p): Declare.
* ipa-prop.cc (ipa_vr::equal_p): New function.
(ipa_agg_pass_through_jf_equivalent_p): Likewise.
(ipa_agg_jump_functions_equivalent_p): Likewise.
(ipa_jump_functions_equivalent_p): Likewise.
* ipa-cp.h (values_equal_for_ipcp_p): Declare.
* ipa-cp.cc (values_equal_for_ipcp_p): Make function public.
* ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h, 
sreal.h,
ipa-cp.h and ipa-prop.h.
(func_checker::compare_gimple_call): Comapre jump functions.

gcc/testsuite/ChangeLog:

2024-03-20  Martin Jambor  

PR ipa/113907
* gcc.dg/lto/pr113907_0.c: New.
* gcc.dg/lto/pr113907_1.c: Likewise.
* gcc.dg/lto/pr113907_2.c: Likewise.

Diff:
---
 gcc/ipa-cp.cc |   2 +-
 gcc/ipa-cp.h  |   2 +
 gcc/ipa-icf-gimple.cc |  30 ++
 gcc/ipa-prop.cc   | 167 ++
 gcc/ipa-prop.h|   3 +
 gcc/testsuite/gcc.dg/lto/pr113907_0.c |  18 
 gcc/testsuite/gcc.dg/lto/pr113907_1.c |  35 +++
 gcc/testsuite/gcc.dg/lto/pr113907_2.c |  11 +++
 8 files changed, 267 insertions(+), 1 deletion(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 2a1da631e9c..b7add455bd5 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -201,7 +201,7 @@ ipcp_lattice::is_single_const ()
 
 /* Return true iff X and Y should be considered equal values by IPA-CP.  */
 
-static bool
+bool
 values_equal_for_ipcp_p (tree x, tree y)
 {
   gcc_checking_assert (x != NULL_TREE && y != NULL_TREE);
diff --git a/gcc/ipa-cp.h b/gcc/ipa-cp.h
index 0b3cfe4b526..7ff74fb5c98 100644
--- a/gcc/ipa-cp.h
+++ b/gcc/ipa-cp.h
@@ -289,4 +289,6 @@ public:
   bool virt_call = false;
 };
 
+bool values_equal_for_ipcp_p (tree x, tree y);
+
 #endif /* IPA_CP_H */
diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 8c2df7a354e..17f62bec068 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -41,7 +41,12 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-walk.h"
 
 #include "tree-ssa-alias-compare.h"
+#include "alloc-pool.h"
+#include "symbol-summary.h"
 #include "ipa-icf-gimple.h"
+#include "sreal.h"
+#include "ipa-cp.h"
+#include "ipa-prop.h"
 
 namespace ipa_icf_gimple {
 
@@ -714,6 +719,31 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)
   && !compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2)))
 return return_false_with_msg ("GIMPLE internal call LHS type mismatch");
 
+  if (!gimple_call_internal_p (s1))
+{
+  cgraph_edge *e1 = cgraph_node::get (m_source_func_decl)->get_edge (s1);
+  cgraph_edge *e2 = cgraph_node::get (m_target_func_decl)->get_edge (s2);
+  class ipa_edge_args *args1 = ipa_edge_args_sum->get (e1);
+  class ipa_edge_args *args2 = ipa_edge_args_sum->get (e2);
+  if ((args1 != nullptr) != (args2 != nullptr))
+   return return_false_with_msg ("ipa_edge_args mismatch");
+  if (args1)
+   {
+ int n1 = ipa_get_cs_argument_count (args1);
+ int n2 = ipa_get_cs_argument_count (args2);
+ if (n1 != n2)
+   return return_false_with_msg ("ipa_edge_args nargs mismatch");
+ for (int i = 0; i < n1; i++)
+   {
+ struct ipa_jump_func *jf1 = ipa_get_ith_jump_func (args1, i);
+ struct ipa_jump_func *jf2 = ipa_get_ith_jump_func (args2, i);
+ if (((jf1 != nullptr) != (jf2 != nullptr))
+ || (jf1 && !ipa_jump_functions_equivalent_p (jf1, jf2)))
+   return return_false_with_msg ("jump function mismatch");
+   }
+   }
+}
+
   return compare_operand (t1, t2, get_operand_access_type (, t1));
 }
 
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index e8e4918d5a8..374e998aa64 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -156,6 +156,20 @@ ipa_vr

[gcc r13-8594] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b

commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor 
Date:   Mon Apr 8 17:34:33 2024 +0200

ipa: Self-DCE of uses of removed call LHSs (PR 108007)

PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.

I have already fixed this for unused parameters in callees, this bug
shows that almost the same thing can happen for removed returns, on
the side of callers.  This means that the issue has to be fixed
elsewhere, in call redirection.  This patch adds a function which
looks for (and through, using a work-list) uses of operations fed
specific SSA names and removes them all.

That would have been easy if it wasn't for debug statements during
tree-inline (from which call redirection is also invoked).  Debug
statements are decoupled from the rest at this point and iterating
over uses of SSAs does not bring them up.  During tree-inline they are
handled especially at the end, I assume in order to make sure that
relative ordering of UIDs are the same with and without debug info.

This means that during tree-inline we need to make a hash of killed
SSAs, that we already have in copy_body_data, available to the
function making the purging.  So the patch duly does also that, making
the interface slightly ugly.  Moreover, all newly unused SSA names
need to be freed and as PR 112616 showed, it must be done in a defined
order, which is what newly added ipa_release_ssas_in_hash does.

This backport to gcc-13 also contains
54e505d0446f86b7ad383acbb8e5501f20872b64 in order not to reintroduce
PR 113757.

gcc/ChangeLog:

2024-04-05  Martin Jambor  

PR ipa/108007
PR ipa/112616
* cgraph.h (cgraph_edge): Add a parameter to
redirect_call_stmt_to_callee.
* ipa-param-manipulation.h (ipa_param_adjustments): Add a
parameter to modify_call.
(ipa_release_ssas_in_hash): Declare.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
parameter killed_ssas, pass it to padjs->modify_call.
* ipa-param-manipulation.cc (purge_all_uses): New function.
(ipa_param_adjustments::modify_call): New parameter killed_ssas.
Instead of substituting uses, invoke purge_all_uses.  If
hash of killed SSAs has not been provided, create a temporary one
and release SSAs that have been added to it.
(compare_ssa_versions): New function.
(ipa_release_ssas_in_hash): Likewise.
* tree-inline.cc (redirect_all_calls): Create
id->killed_new_ssa_names earlier, pass it to edge redirection,
adjust a comment.
(copy_body): Release SSAs in id->killed_new_ssa_names.

gcc/testsuite/ChangeLog:

2024-01-15  Martin Jambor  

PR ipa/108007
PR ipa/112616
* gcc.dg/ipa/pr108007.c: New test.
* gcc.dg/ipa/pr112616.c: Likewise.

(cherry picked from commit a9a8426e534760b8d3a250e9bd3cff4db131a2be)

Diff:
---
 gcc/cgraph.cc   |  10 +++-
 gcc/cgraph.h|   9 ++-
 gcc/ipa-param-manipulation.cc   | 112 +---
 gcc/ipa-param-manipulation.h|   5 +-
 gcc/testsuite/g++.dg/ipa/pr113757.C |  14 +
 gcc/testsuite/gcc.dg/ipa/pr108007.c |  32 +++
 gcc/testsuite/gcc.dg/ipa/pr112616.c |  28 +
 gcc/tree-inline.cc  |  27 -
 8 files changed, 193 insertions(+), 44 deletions(-)

diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
index ec663d23385..7a14c00b60a 100644
--- a/gcc/cgraph.cc
+++ b/gcc/cgraph.cc
@@ -1403,11 +1403,17 @@ cgraph_edge::redirect_callee (cgraph_node *n)
speculative indirect call, remove "speculative" of the indirect call and
also redirect stmt to it's final direct target.
 
+   When called from within tree-inline, KILLED_SSAs has to contain the pointer
+   to killed_new_ssa_names within the copy_body_data structure and SSAs
+   discovered to be useless (if LHS is removed) will be added to it, otherwise
+   it needs to be NULL.
+
It is up to caller to iteratively transform each "speculative"
direct call as appropriate.  */
 
 gimple *
-cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
+cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e,
+  hash_set  *killed_ssas)
 {
   tree decl = gimple_call_fndecl (e->call_stmt);
   gcall *new_stmt;
@@ -1527,7 +1533,7 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
 

[gcc r14-9813] ipa: Force args obtined through pass-through maps to the expected type (PR 113964)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe

commit r14-9813-g8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe
Author: Martin Jambor 
Date:   Fri Apr 5 18:18:39 2024 +0200

ipa: Force args obtined through pass-through maps to the expected type (PR 
113964)

Interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid.  PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these union parameters are split with IPA-SRA.  The
leaf function however uses a signed short member of the union.

In the calling function, we get the unsigned constant as the
replacement for the union and it is then passed in the call without
any type compatibility checks.  Apparently on riscv64 it matters
whether the parameter is signed or unsigned short and so the leaf
function can see different values.

Fixed by using useless_type_conversion_p at the appropriate place and
if it fails, use force_value_to type as elsewhere in similar
situations.

gcc/ChangeLog:

2024-04-04  Martin Jambor  

PR ipa/113964
* ipa-param-manipulation.cc (ipa_param_adjustments::modify_call):
Force values obtined through pass-through maps to the expected
split type.

gcc/testsuite/ChangeLog:

2024-04-04  Patrick O'Neill  
Martin Jambor  

PR ipa/113964
* gcc.dg/ipa/pr114247.c: New test.

Diff:
---
 gcc/ipa-param-manipulation.cc   |  6 ++
 gcc/testsuite/gcc.dg/ipa/pr114247.c | 31 +++
 2 files changed, 37 insertions(+)

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index f4b5e850c2b..ad36b8389c0 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -740,6 +740,12 @@ ipa_param_adjustments::modify_call (cgraph_edge *cs,
  }
   if (repl)
{
+ if (!useless_type_conversion_p(apm->type, repl->typed.type))
+   {
+ repl = force_value_to_type (apm->type, repl);
+ repl = force_gimple_operand_gsi (, repl,
+  true, NULL, true, GSI_SAME_STMT);
+   }
  vargs.quick_push (repl);
  continue;
}
diff --git a/gcc/testsuite/gcc.dg/ipa/pr114247.c 
b/gcc/testsuite/gcc.dg/ipa/pr114247.c
new file mode 100644
index 000..60aa2bc0122
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr114247.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsigned-char -fno-strict-aliasing -fwrapv" } */
+
+union a {
+  unsigned short b;
+  int c;
+  signed short d;
+};
+int e, f = 1, g;
+long h;
+const int **i;
+void j(union a k, int l, unsigned m) {
+  const int *a[100];
+  i = [0];
+  h = k.d;
+}
+static int o(union a k) {
+  k.d = -1;
+  while (1)
+if (f)
+  break;
+  j(k, g, e);
+  return 0;
+}
+int main() {
+  union a n = {1};
+  o(n);
+  if (h != -1)
+__builtin_abort();
+  return 0;
+}

Re: [GSoC] Application RFC + Question - GENERIC dump

[Martin Jambor]

Hello,

On Fri, Apr 05 2024, Richard Biener via Gcc wrote:
> On Tue, Apr 2, 2024 at 1:16 PM Richard Biener
>  wrote:
>>
>> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc
>>  wrote:
>> >
>> > Forgot to CC the mailing list - mea culpa.
>> >
>> > -- Forwarded message -
>> > From: Thor Preimesberger 
>> > Date: Tue, Apr 2, 2024 at 5:57 PM
>> > Subject: Re: [GSoC] Application RFC + Question - GENERIC dump
>> > To: Richard Biener 
>> >
>> >
>> > Thanks for the quick feedback, especially on such short notice - I'll
>> > get the actual GSoC application in, within a couple of hours.
>> >
>> > > This looks like a reasonable timeline and overall project structure.  I 
>> > > probably
>> > > pointed to it in my responses to the initial patch but to repeat here
>> > > it would be
>> > > very nice to integrate with the existing GENERIC dumping in 
>> > > tree-pretty-print.cc
>> > > That's what you get when calling 'debug_tree ()' from the inferior 
>> > > inside
>> > > gdb.  Implementation-wise the JSON target would then be a new
>> > > dump flag (see the various TDF_* in dumpfiles.h).
>> >
>> > Understood - To check my understanding, is it correct to say that we
>> > essentially want to parse the output of tree-pretty-print.cc into
>> > JSON?
>>
>> No, we want to emit JSON directly from tree-pretty-print.cc conditional
>> of the new dump flag.
>
> Thanks for uploading the proposal.  Can you please update it to remove
> the confusion around "parsing of the tree-pretty-print.cc output"?

IIUC proposals cannot be altered past the Tuesday deadline.  Still, they
probably can clarified somewhat here even in the upcoming days (but
really not much more than that), so that all involved parties are then
not surprised if the project needs to take a slightly different
direction (assuming it will be selected AND we get enough slots in the
program from Google).

Thanks,

Martin


> As
> said we instead want to emit JSON directly from the GENERIC representation
> as it is in memory, preferably as an output variant to the existing
> tree-pretty-print.cc output to make it easy to keep both variants in sync.
>
> As for the timeline and way of development I would strongly suggest to
> develop the JSON -> html (or JSON -> graphviz if you like that more)
> translator in parallel to be able to incrementally verify the user consumed
> output is as desired.  Unimplemented JSON bits can be always
> implemented as text JSON nodes containing the textual tree-pretty-print.cc
> output.
>
> One of the important goals is to have the JSON output functionality
> in tree-pretty-print.cc implemented in a maintainable way, making it
> easy to adjust JSON/non-JSON output when the data structures change.
>
> Thanks,
> Richard.
>
>> > Then, this parser then would be used in a new dump pass, from
>> > either inside gdb or from gcc itself, to dump the JSON wherever it
>> > needs to go.
>>
>> For the actual -fdump-generic-nodes we would call the dumper with the
>> new flag and likely have set up the output to a file.
>>
>> > So ultimately the idea is to create both the parser and a new dump pass 
>> > from it.
>>
>> I don't think there's a parser involved, in the end we'd have to
>> "parse" the JSON
>> to produce HTML or graphviz output, but the JSON emission would be from
>> inside dump_generic_node (and sibliings), conditional on the dump flag.  Note
>> that a lot of things will be dumped the same such as identifiers or 
>> constants,
>> but all structured bits would be different.
>>
>> Richard.
>>
>> > I just read the notes you gave on the original patch. I'll edit the
>> > plan a bit to emphasize interworking with tree-pretty-print, and
>> > checking the bugs that mention easyhack.
>> >
>> > Best,
>> > Thor Preimesberger
>> >
>> >
>> > On Tue, Apr 2, 2024 at 4:20 PM Richard Biener
>> >  wrote:
>> > >
>> > > On Mon, Apr 1, 2024 at 6:23 PM Thor Preimesberger via Gcc
>> > >  wrote:
>> > > >
>> > > > Hey all,
>> > > >
>> > > > I'm joining the group of people submitting their GSoC applications
>> > > > over the holiday. I'm interested in the "Implement structured dumping
>> > > > of GENERIC" project idea, and the application I've written is below.
>> > >
>> > > Thank you for the interest in this project.
>> > >
>> > > > A quick question before though:
>> > > >
>> > > > - What would the expected use cases of the proposed
>> > > > -fdump-generic-nodes option be, in addition to, presumably, writing
>> > > > front ends into gcc?
>> > >
>> > > I think the main use case is better "visual" debugging and understanding
>> > > of GENERIC.  Then a structured dumping would also allow to custom
>> > > processing like doing memory or other statistics.
>> > >
>> > > >I'm also curious about also targeting .gz/Graphviz; on a first
>> > > > blush, it doesn't seem like too much additional work, and it may be
>> > > > useful for the above applications. But I imagine there may be other
>> > > > ways to process the data that would 

[PATCH] ipa: Force args obtined through pass-through maps to the expected type (PR 113964)

[Martin Jambor]

Hi,

interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid.  PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these union parameters are split with IPA-SRA.  The
leaf function however uses a signed short member of the union.

In the calling function, we get the unsigned constant as the
replacement for the union and it is then passed in the call without
any type compatibility checks.  Apparently on riscv64 it matters
whether the parameter is signed or unsigned short and so the leaf
function can see different values.

Fixed by using useless_type_conversion_p at the appropriate place and
if it fails, use force_value_to type as elsewhere in similar
situations.

Bootstrapped and tested on x86_64-linux, the reporter has also run the
testsuite with this patch on riscv64 and reported in Bugzilla there were
no issues.

OK for master and GCC 13?

Thanks,

Martin


gcc/ChangeLog:

2024-04-04  Martin Jambor  

PR ipa/113964
* ipa-param-manipulation.cc (ipa_param_adjustments::modify_call):
Force values obtined through pass-through maps to the expected
split type.

gcc/testsuite/ChangeLog:

2024-04-04  Patrick O'Neill  
Martin Jambor  

PR ipa/113964
* gcc.dg/ipa/pr114247.c: New test.
---
 gcc/ipa-param-manipulation.cc   |  6 ++
 gcc/testsuite/gcc.dg/ipa/pr114247.c | 31 +
 2 files changed, 37 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr114247.c

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 3e0df6a6f77..b4ca78b652e 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -740,6 +740,12 @@ ipa_param_adjustments::modify_call (cgraph_edge *cs,
  }
   if (repl)
{
+ if (!useless_type_conversion_p(apm->type, repl->typed.type))
+   {
+ repl = force_value_to_type (apm->type, repl);
+ repl = force_gimple_operand_gsi (, repl,
+  true, NULL, true, GSI_SAME_STMT);
+   }
  vargs.quick_push (repl);
  continue;
}
diff --git a/gcc/testsuite/gcc.dg/ipa/pr114247.c 
b/gcc/testsuite/gcc.dg/ipa/pr114247.c
new file mode 100644
index 000..60aa2bc0122
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr114247.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsigned-char -fno-strict-aliasing -fwrapv" } */
+
+union a {
+  unsigned short b;
+  int c;
+  signed short d;
+};
+int e, f = 1, g;
+long h;
+const int **i;
+void j(union a k, int l, unsigned m) {
+  const int *a[100];
+  i = [0];
+  h = k.d;
+}
+static int o(union a k) {
+  k.d = -1;
+  while (1)
+if (f)
+  break;
+  j(k, g, e);
+  return 0;
+}
+int main() {
+  union a n = {1};
+  o(n);
+  if (h != -1)
+__builtin_abort();
+  return 0;
+}
-- 
2.44.0

[PATCH] ICF: Make ICF and SRA agree on padding

[Martin Jambor]

Hi,

PR 113359 shows that (at least with -fno-strict-aliasing) ICF can
unify two functions which copy an aggregate type of the same size but
then SRA, through its total scalarization, can copy the aggregate by
pieces, skipping paddding, but the padding was not the same in the two
original functions that ICF unified.

This patch enhances SRA with the ability to collect padding
information which then can be compared from within ICF.  Unfortunately
SRA uses OPTION_SET_P when determining its limits, so ICF needs to
switch cfuns at least once to figure it out too.

The patch has been approved by Honza in Bugzilla. (I hope.  He did write
it looked reasonable.)  Together with the patch for PR 113907, it has
passed bootstrap, LTO bootstrap and LTO profiledbootstrap and testing on
x86_64-linux and bootstrap and LTO bootstrap on ppc64le-linux.  It also
passed normal bootstrap on aarch64-linux but there many testcases failed
because the compiler timed out.  The machine is old and slow and might
have been oversubscribed so my plan is to try again on gcc185 from
cfarm.  If that goes well, I intend to commit the patch and then start
working on backports.

Martin


gcc/ChangeLog:

2024-03-27  Martin Jambor  

PR ipa/113359
* ipa-icf-gimple.h (func_checker): New members
safe_for_total_scalarization_p, m_total_scalarization_limit_known_p
and m_total_scalarization_limit.
(func_checker::func_checker): Initialize new member variables.
* ipa-icf-gimple.cc: Include tree-sra.h.
(func_checker::func_checker): Initialize new member variables.
(func_checker::safe_for_total_scalarization_p): New function.
(func_checker::compare_operand): Use the new function.
* tree-sra.h (sra_get_max_scalarization_size): Declare.
(sra_total_scalarization_would_copy_same_data_p): Likewise.
* tree-sra.cc (prepare_iteration_over_array_elts): New function.
(class sra_padding_collecting): New.
(sra_padding_collecting::record_padding): Likewise.
(scalarizable_type_p): Rename to totally_scalarizable_type_p.  Add
ability to record padding when requested.
(totally_scalarize_subtree): Split out gathering information necessary
to iterate over array elements to prepare_iteration_over_array_elts.
Fix errornous early exit.
(analyze_all_variable_accesses): Adjust the call to
totally_scalarizable_type_p.  Move determining of total scalariation
size limit...
(sra_get_max_scalarization_size): ...here.
(check_ts_and_push_padding_to_vec): New function.
(sra_total_scalarization_would_copy_same_data_p): Likewise.

gcc/testsuite/ChangeLog:

2024-03-27  Martin Jambor  

PR ipa/113359
* gcc.dg/lto/pr113359-1_0.c: New.
* gcc.dg/lto/pr113359-1_1.c: Likewise.
* gcc.dg/lto/pr113359-2_0.c: Likewise.
* gcc.dg/lto/pr113359-2_1.c: Likewise.
* gcc.dg/lto/pr113359-3_0.c: Likewise.
* gcc.dg/lto/pr113359-3_1.c: Likewise.
* gcc.dg/lto/pr113359-4_0.c: Likewise.
* gcc.dg/lto/pr113359-4_1.c: Likewise.
* gcc.dg/lto/pr113359-5_0.c: Likewise.
* gcc.dg/lto/pr113359-5_1.c: Likewise.
---
 gcc/ipa-icf-gimple.cc   |  41 +++-
 gcc/ipa-icf-gimple.h|  15 +-
 gcc/testsuite/gcc.dg/lto/pr113359-1_0.c |  86 
 gcc/testsuite/gcc.dg/lto/pr113359-1_1.c |  38 
 gcc/testsuite/gcc.dg/lto/pr113359-2_0.c |  87 
 gcc/testsuite/gcc.dg/lto/pr113359-2_1.c |  38 
 gcc/testsuite/gcc.dg/lto/pr113359-3_0.c | 114 +++
 gcc/testsuite/gcc.dg/lto/pr113359-3_1.c |  49 +
 gcc/testsuite/gcc.dg/lto/pr113359-4_0.c | 114 +++
 gcc/testsuite/gcc.dg/lto/pr113359-4_1.c |  49 +
 gcc/testsuite/gcc.dg/lto/pr113359-5_0.c | 118 +++
 gcc/testsuite/gcc.dg/lto/pr113359-5_1.c |  50 +
 gcc/tree-sra.cc | 252 +++-
 gcc/tree-sra.h  |   3 +
 14 files changed, 999 insertions(+), 55 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-1_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-1_1.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-2_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-2_1.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-3_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-3_1.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-4_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-4_1.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-5_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113359-5_1.c

diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 17f62bec068..c25eb24710f 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgloop.h"
 #include "attribs.h"
 #include "gimple-walk.h"
+#in

[PATCH] ipa: Compare jump functions in ICF (PR 113907)

[Martin Jambor]

Hello,

In PR 113907 comment #58, Honza found a case where ICF thinks bodies
of functions are equivalent but becaise of difference in aliases in a
memory access, different aggregate jump functions are associated with
supposedly equivalent call statements.  This patch adds a way to
compare jump functions and plugs it into ICF to avoid the issue.

The patch has been approved by Honza in Bugzilla.  Together with the
patch for PR 113359, it has passed bootstrap, LTO bootstrap and LTO
profiledbootstrap and testing on x86_64-linux and bootstrap and LTO
bootstrap on ppc64le-linux.  It also passed normal bootstrap on
aarch64-linux but there many testcases failed because the compiler timed
out.  The machine is old and slow and might have been oversubscribed so
my plan is to try again on gcc185 from cfarm.  If that goes well, I
intend to commit the patch and then start working on backports.

Martin


gcc/ChangeLog:

2024-03-20  Martin Jambor  

PR ipa/113907
* ipa-prop.h (class ipa_vr): Declare new overload of a member function
equal_p.
(ipa_jump_functions_equivalent_p): Declare.
* ipa-prop.cc (ipa_vr::equal_p): New function.
(ipa_agg_pass_through_jf_equivalent_p): Likewise.
(ipa_agg_jump_functions_equivalent_p): Likewise.
(ipa_jump_functions_equivalent_p): Likewise.
* ipa-cp.h (values_equal_for_ipcp_p): Declare.
* ipa-cp.cc (values_equal_for_ipcp_p): Make function public.
* ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h, sreal.h,
ipa-cp.h and ipa-prop.h.
(func_checker::compare_gimple_call): Comapre jump functions.

gcc/testsuite/ChangeLog:

2024-03-20  Martin Jambor  

PR ipa/113907
* gcc.dg/lto/pr113907_0.c: New.
* gcc.dg/lto/pr113907_1.c: Likewise.
* gcc.dg/lto/pr113907_2.c: Likewise.
---
 gcc/ipa-cp.cc |   2 +-
 gcc/ipa-cp.h  |   2 +
 gcc/ipa-icf-gimple.cc |  30 +
 gcc/ipa-prop.cc   | 167 ++
 gcc/ipa-prop.h|   3 +
 gcc/testsuite/gcc.dg/lto/pr113907_0.c |  18 +++
 gcc/testsuite/gcc.dg/lto/pr113907_1.c |  35 ++
 gcc/testsuite/gcc.dg/lto/pr113907_2.c |  11 ++
 8 files changed, 267 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113907_0.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113907_1.c
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr113907_2.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 2a1da631e9c..b7add455bd5 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -201,7 +201,7 @@ ipcp_lattice::is_single_const ()
 
 /* Return true iff X and Y should be considered equal values by IPA-CP.  */
 
-static bool
+bool
 values_equal_for_ipcp_p (tree x, tree y)
 {
   gcc_checking_assert (x != NULL_TREE && y != NULL_TREE);
diff --git a/gcc/ipa-cp.h b/gcc/ipa-cp.h
index 0b3cfe4b526..7ff74fb5c98 100644
--- a/gcc/ipa-cp.h
+++ b/gcc/ipa-cp.h
@@ -289,4 +289,6 @@ public:
   bool virt_call = false;
 };
 
+bool values_equal_for_ipcp_p (tree x, tree y);
+
 #endif /* IPA_CP_H */
diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 8c2df7a354e..17f62bec068 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -41,7 +41,12 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-walk.h"
 
 #include "tree-ssa-alias-compare.h"
+#include "alloc-pool.h"
+#include "symbol-summary.h"
 #include "ipa-icf-gimple.h"
+#include "sreal.h"
+#include "ipa-cp.h"
+#include "ipa-prop.h"
 
 namespace ipa_icf_gimple {
 
@@ -714,6 +719,31 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)
   && !compatible_types_p (TREE_TYPE (t1), TREE_TYPE (t2)))
 return return_false_with_msg ("GIMPLE internal call LHS type mismatch");
 
+  if (!gimple_call_internal_p (s1))
+{
+  cgraph_edge *e1 = cgraph_node::get (m_source_func_decl)->get_edge (s1);
+  cgraph_edge *e2 = cgraph_node::get (m_target_func_decl)->get_edge (s2);
+  class ipa_edge_args *args1 = ipa_edge_args_sum->get (e1);
+  class ipa_edge_args *args2 = ipa_edge_args_sum->get (e2);
+  if ((args1 != nullptr) != (args2 != nullptr))
+   return return_false_with_msg ("ipa_edge_args mismatch");
+  if (args1)
+   {
+ int n1 = ipa_get_cs_argument_count (args1);
+ int n2 = ipa_get_cs_argument_count (args2);
+ if (n1 != n2)
+   return return_false_with_msg ("ipa_edge_args nargs mismatch");
+ for (int i = 0; i < n1; i++)
+   {
+ struct ipa_jump_func *jf1 = ipa_get_ith_jump_func (args1, i);
+ struct ipa_jump_func *jf2 = ipa_get_ith_jump_func (args2, i);
+ if (((jf1 != nullptr) != (jf2 != nullptr))
+ || (jf1 && !ipa_jump_functions_equivalent_p (jf

[gcc r14-9794] ipa: Avoid duplicate replacements in IPA-SRA transformation phase

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:ca56b43105fc09021ec445f1978a17cd85ae5e0c

commit r14-9794-gca56b43105fc09021ec445f1978a17cd85ae5e0c
Author: Martin Jambor 
Date:   Thu Apr 4 22:46:16 2024 +0200

ipa: Avoid duplicate replacements in IPA-SRA transformation phase

When the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the propagation in GIMPLE because that is the last
moment the parameter exists).

However, when IPA-SRA wants to split out a smaller aggregate out
of an aggregate, which happens to be of the same size as a known
scalar constant at the same offset, the transformation bit fails to
recognize the situation, tries to do both splitting and constant
propagation and in PR 111571 testcase creates a nonsensical call
statement on which the call redirection then ICEs.

Fixed by making sure we don't try to do two replacements of the same
part of the same parameter.

The look-up among replacements requires these are sorted and this
patch just sorts them if they are not already sorted before each new
look-up.  The worst number of sortings that can happen is number of
parameters which are both split and have aggregate constants times
param_ipa_max_agg_items (default 16).  I don't think complicating the
source code to optimize for this unlikely case is worth it but if need
be, it can of course be done.

gcc/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::common_initialization): Avoid creating
duplicate replacement entries.

gcc/testsuite/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* gcc.dg/ipa/pr111571.c: New test.

Diff:
---
 gcc/ipa-param-manipulation.cc   | 16 
 gcc/testsuite/gcc.dg/ipa/pr111571.c | 29 +
 2 files changed, 45 insertions(+)

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 3e0df6a6f77..f4b5e850c2b 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -1525,6 +1525,22 @@ ipa_param_body_adjustments::common_initialization (tree 
old_fndecl,
 replacement with a constant (for split aggregates passed
 by value).  */
 
+ if (split[parm_num])
+   {
+ /* We must be careful not to add a duplicate
+replacement. */
+ sort_replacements ();
+ ipa_param_body_replacement *pbr
+   = lookup_replacement_1 (m_oparms[parm_num],
+   av.unit_offset);
+ if (pbr)
+   {
+ /* Otherwise IPA-SRA should have bailed out.  */
+ gcc_assert (AGGREGATE_TYPE_P (TREE_TYPE (pbr->repl)));
+ continue;
+   }
+   }
+
  tree repl;
  if (av.by_ref)
repl = av.value;
diff --git a/gcc/testsuite/gcc.dg/ipa/pr111571.c 
b/gcc/testsuite/gcc.dg/ipa/pr111571.c
new file mode 100644
index 000..2a4adc608db
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr111571.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2"  } */
+
+struct a {
+  int b;
+};
+struct c {
+  long d;
+  struct a e;
+  long f;
+};
+int g, h, i;
+int j() {return 0;}
+static void k(struct a l, int p) {
+  if (h)
+g = 0;
+  for (; g; g = j())
+if (l.b)
+  break;
+}
+static void m(struct c l) {
+  k(l.e, l.f);
+  for (;; --i)
+;
+}
+int main() {
+  struct c n = {10, 9};
+  m(n);
+}

Re: [GSoC] Interest in applying

[Martin Jambor]

Hello,

On Sun, Mar 31 2024, tmpod via Gcc wrote:
> Hello,
>
> I am a Computer Science student, currently taking a Master's degree in
>   
> 
> Portugal's top university. I have a strong passion for algorithms, data   
>   
> 
> structures and high performance computing, having participated in many
>   
> 
> programming contests (nationals, SWERC, Google's now defunct  
>   
> 
> competitions, etc) too. I have also some experience in contributing to
>   
> 
> open-source and working in software development teams. 
> C and C++ are the languages I've used the most, always compiled with
> GCC. My fascination with this area of computer science, and especially
> with GCC's details, has been present since an early age, so this Google
> program felt like the perfect opportunity to act and learn more!
>
> After carefully reading your approved ideas page, the ones that stand 
>   
> 
> out more to me are:
> * Improving OpenACC support
> * Extending the static analysis pass (for format strings, in particular)
> * Improving nothrow detection
>
> I have read the "Before you apply" and completed some of the steps
> outlined, and will do so as well for the remaining, tomorrow.
>
> I am aware of the very tight deadline and that it may be hard to write a
> community-backed proposal now, but unfortunately I was only made aware
> of Google's program a couple of days ago. Still, I'm going to try my
> best to write a quality proposal until Tuesday.
>
> If you have any suggestions, please let me know!
> I'd love to further discuss these with you.
>

We are delighted you found contributing to GCC interesting.

As you correctly wrote, the deadline is tight and so I cannot really write
more than that we are looking forward to see your application - and Easter
has made the situation worse).  Most of the projects you have listed have
been discussed on the mailing list recently, so hopefully you have found
some of the notes in the archive.  

Good luck!

Martin

Re: GSoC Timeline Review

[Martin Jambor]

Hello,

On Sat, Mar 30 2024, Nada Elsayed via Gcc wrote:
> I think that I didn't fully understand the project, so I read more and
> updated the Timeline Suggestion.

Sorry that we were for not being able to respond sooner, Easter got into
way in an unfortunate way.  I do not know much about Cython or static
analysis (so I would not be able to give much advice about improvements
to the time-line), but can confirm we have received your application.

Thanks a lot.

Martin

>
> Suggested Timeline:
>
>-
>
>May 1-26:
>-
>
>   Explore Cython modules and try more realistic codes to see how it
>   translates Python to c/c++.
>   -
>
>   Know more about entry-points that Cython uses.
>   -
>
>   Understand common bugs that happen when converting Python to c/c++.
>
>
>
>-
>
>Explore static analysis tool for CPython Extension code -which is
>written in Python- and try this analyzer to understand the bugs in
>translated Python code fully.
>-
>
>Know how we can emit warnings and errors.
>
>
>
>-
>
>Debug the codebase to grasp its structure and potential areas for
>improvement.
>
>
>-
>
>Weeks 1-2:
>-
>
>   Understand more about reference counting verification.
>   -
>
>   Develop verifying reference counts for PyObjects passed as parameters.
>   -
>
>Weeks 3-4:
>-
>
>   Begin to investigate Error Handling Checking.
>   -
>
>   Understand how the Static Analysis tool does Error Handling checking.
>   -
>
>   Implement these checks in the plugin.
>   -
>
>Weeks 5-7:
>-
>
>   Begin to investigate Exception Handling Checking.
>   -
>
>   Understand how the Static Analysis tool does Exception Handling
>   checking.
>   -
>
>   Implement these checks in the plugin.
>   -
>
>Weeks 8-11
>-
>
>   Begin to investigate Format String Checking.
>   -
>
>   Understand how the Static Analysis tool does Format String Checking.
>   -
>
>   Implement these checks in the plugin.
>   -
>
>Week 12
>-
>
>   Writing the GSoC wrapping-up document.
>
>
> ‫في الأربعاء، 27 مارس 2024 في 2:31 ص تمت كتابة ما يلي بواسطة ‪Nada
> Elsayed‬‏ <‪nadaelsayed...@gmail.com‬‏>:‬
>
>> Greetings All,
>> Hope this email finds you well.
>> I am interested in "Extend the plugin to add checking for usage of the
>> CPython API" project. First of all, I built the library, and now I am
>> trying to debug it. Then, I also used Cpython in 3 demos to understand how
>> it works. Finally, I read the uploaded patch comments to understand the
>> codebase and file structure.
>>
>> I was wondering if you could review my suggested timeline?
>> suggested Timeline:
>>
>>-
>>
>>May 1-26:
>>-
>>
>>   Explore Cython modules, emphasizing entry-points and bug
>>   identification.
>>   -
>>
>>   Study analyzers, particularly cpy-analyzer, to enhance
>>   understanding.
>>   -
>>
>>   Debug the codebase to grasp its structure and potential areas for
>>   improvement.
>>   -
>>
>>   Focus investigation on "errors in GIL handling" and "tp_traverse
>>   errors".
>>   -
>>
>>Weeks 1-6:
>>-
>>
>>   Investigate GIL (Global Interpreter Lock) errors extensively.
>>   -
>>
>>   Engage in discussions and develop viable solutions to address
>>   identified issues.
>>
>>
>>
>>-
>>
>>Weeks 7-12:
>>-
>>
>>   Gain insight into the functioning of the Garbage Collector.
>>   -
>>
>>   Implement checks to mitigate traverse errors effectively.
>>   -
>>
>>   Ensure robust error handling mechanisms are in place through
>>   thorough study and practical implementation.
>>
>>

Re: "GSoC"

[Martin Jambor]

Hello,

I actually forgot to CC the mailing list as I promised to, so
re-sending.

Sorry,

Martin


On Sat, Mar 30 2024, Martin Jambor wrote:
> Hello,
>
> and sorry for replying late, I have faced a few urgent interruptions
> last week and unfortunately it is also a short week because of Easter -
> and so will be the upcoming one, I'm afraid, as Monday is also public
> holiday in many countries.
>
> Some comments are inline below.
>
> On Wed, Mar 27 2024, M Hamza Nadeem wrote:
>> Hi Martin,
>>
>> *Firstly* ,I have diligently followed the instructions provided in the
>> "Before you apply" section of the GCC GSoC page and successfully completed
>> the tasks outlined therein. I have built, installed, and tested GCC . I
>> have attached the screenshot of it below .
>> [image: gmail.png]
>>
>>  *Secondly*, I had Generated dumps of the Intermediate Representation of a
>> simple compiled program and stepped through some functions during
>> compilation using a debugger. I am studying  more deeply this concept at
>> https://www.geeksforgeeks.org/intermediate-code-generation-in-compiler-design/
>>  .
>>
>
> Thank you, that is important.
>
>> *Thirdly *, After conducting a thorough review of the available projects
>> listed on the GCC GSoC page, I have identified a project that aligns
>> closely with my interests and skill set. The project titled "Improve
>> nothrow Detection in GCC," under the mentorship of Jan Hubička,
>> particularly caught my attention.
>>
>> The prospect of extending the GCC middle-end to comprehend the semantics of
>> a __cxa_throw call and enable type-sensitive propagation of thrown
>> exceptions  I am particularly drawn to this project due to its intersection
>> with my academic background and professional interests.
>>
>> As __cxa_throw is a low-level function provided by the C/C++ ABI
>> (Application Binary Interface) used for throwing exceptions in C/C++
>> programs. It is typically implemented as part of the C/C++ runtime library.
>> This function is invoked when a throw statement is encountered in C/C++
>> code.
>>
>> Throughout my university studies, I have undertaken in-depth coursework in
>> Assembly language. This foundational knowledge has equipped me with a solid
>> understanding of low-level keywords , their significance within the context
>> of compiler design.
>>
>> Furthermore, my academic curriculum has provided me with a comprehensive
>> understanding of core programming concepts, including polymorphism,
>> inheritance, aggregation, data structures and Inter-process communication .
>> I have also gained practical experience in implementing these concepts
>> through various programming assignments and projects.
>>
>> I firmly believe that my academic background, coupled with my enthusiasm
>> for compiler technology  positions me well to contribute meaningfully to
>> the improvement of nothrow detection in GCC. With the guidance and
>> mentorship of experienced professionals ,  I am confident in my ability to
>> navigate the complexities of this project and propose effective solutions.
>>
>> *Fourthly *, As the deadline for submitting proposals for the GSoC 2024
>> program approaches rapidly, I am reaching out to seek your guidance on the
>> essential topics that should be addressed within my proposal for securing
>> an internship position within the GNU Compiler Collection (GCC).
>
> In a general form, it is all described here:
> https://gcc.gnu.org/wiki/SummerOfCode#Application
>
> More information about this project has been given for example at the
> end of https://gcc.gnu.org/pipermail/gcc/2024-March/243512.html (don't
> be confused by the subject, the thread discusses two projects).
>
> Which brings me to the point that , these questions should be directed
> to the mailing list (which I am CCing) where you can reach mentors and
> other people who know more about these things than me.
>
> Good luck,
>
> Martin
>
>
>>
>> Warm regards,
>> M Hamza Nadeem
>>
>> On Mon, Mar 25, 2024 at 9:54 PM M Hamza Nadeem 
>> wrote:
>>
>>> Thanks, I'll check them out.
>>>
>>> On Mon, 25 Mar 2024, 9:50 pm Martin Jambor,  wrote:
>>>
>>>> Hello,
>>>>
>>>> On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote:
>>>> > Hi Sir / mam,
>>>> >
>>>> >
>>>> > I hope this email finds you well. As an enthusiastic contributor with a
>>>> > strong grasp of C/C++ and familiarity with Rust, I am eager to explore

Re: GSoC

[Martin Jambor]

Hello Abhinav,

sorry for a very brief answer, I'm not much online during Easter (the
timing of the application deadline is a bit unfortunate in this regard).

On Sat, Mar 30 2024, Abhinav Gupta wrote:
> Hello GCC community,
>  Since resuming work for the GSoC proposal recently, I have made
> significant progress in understanding the code snippets provided by
> Mr. Jambor and delved into the libgomp folder, compiling random
> snippets in the examples folder and reading the IR. Building GCC from
> source has also provided me with a deeper understanding of its inner
> workings.
> I've also looked at the GOMP_target_ext function and its
> implementations for both the existing targets as pointed out by Mr.
> Schwinge, these config folders have also given me an understanding of
> what is actually expected for this project, however I need some
> clarity regarding a few things-
>
> The GOMP_* functions calls for different targets: I need further
> assistance to understand how they should be implemented for the host
> machine, I am aware that this is exactly what the project is, I am
> just looking for a start point.

Look at functions with names starting with GOMP_OFFLOAD (such as
GOMP_OFFLOAD_run) in files in src/libgomp/plugin/*.c - those are the
things you'll need to implement but instead of setting up a GPU and
talking to AMD HSA or Nvidia CUDA you'll be setting up a new process and
communicating with it.

The entire list of functions that a plugin can have (probably not all
have to be implemented) is in struct gomp_device_descr in libgomp.h.

>
> Host Fallback Mode: I came across mentions of a host fallback mode in
> the offloading Wiki page and as you mentioned that there is already a
> oacc-host.c api. Could you please provide more clarity on whether this
> existing feature can be repurposed for offloading to a separate
> process on the same host? If not, could you elaborate on what exactly
> the host fallback mode is and how it differs from the proposed
> offloading mechanism?

Partially.  The host fallback means that, for one reason or another
(most commonly because the machine does not have any accelerators to
which it can offload), the OpenMP run time simply runs the target
regions on the CPU, almost as if it was not there (but there are
caveats, of course).

Which means that the outlined regions can be compiled basically as they
are for host fallback (though doing it with the same compiler will be
funny), on the GOMP side, things will need to look very differently.

I hope this helps,

Martin


>
> Thanking you
> Abhinav
>
> On Fri, 15 Mar 2024 at 03:54, Thomas Schwinge  wrote:
>>
>> Hi Abhinav!
>>
>> Thanks for your interest in contributing to GCC, and thanks to Martin for
>> all the information you already provided.  Just a bit more, to get you
>> started on developing a proper project proposal:
>>
>> On 2024-03-13T14:54:52+0100, Martin Jambor  wrote:
>> > On Tue, Mar 12 2024, Abhinav Gupta wrote:
>> >> I looked at all the links you provided in the reply and read the
>> >> paper cited on the GCC page for GSoC. I also looked into the rust
>> >> frontend project during this time, and the Offloading project
>> >> interests me more, so I will focus solely on it in the remaining seven
>> >> days before the deadline for GSoC application submission.
>> >
>> > AFAIU, in five days (from now) the application period *opens*, the
>> > deadline is 2nd April.  Still it is good idea not to lose any time.
>>
>> Indeed, no rush yet.  :-)
>>
>> >> Are there other resources I can look at to better understand the whole
>> >> process?
>>
>> At some point, no too late, you should spend some time on learning how to
>> build GCC, and run the test suite.
>> <https://gcc.gnu.org/wiki/SummerOfCode> and
>> <https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development> have
>> some pointers to get started.  If you have specific questions, we're
>> happy to help, of course.
>>
>> >> Reading the git commit on the website is proving to be very
>> >> slow.
>>
>> Yes, that's not going to be necessary.
>>
>> >> I think the git commit about Intel MIC would be like a
>> >> "template" in loose terms
>>
>> Right, that's in fact a very good description.  The idea here is not to
>> bring back the whole Intel MIC emulator, but something very much simpler.
>>
>> >> to implement the host-ISA mode at least, but
>> >> for the libgomp plugin, I need a better understanding.
>>
>> Find existing libgomp plugins as 'libgomp/plugin/plugin-*.c'.  The
>> 'GOMP_OFFLOAD_[

Re: Initial draft of GSOC proposal - Offloading to a separate process on the same host.

[Martin Jambor]

Hello,

On Wed, Mar 27 2024, Soumya Ranjan wrote:
> Hello!
> Thanks for your response Martin!
> Sorry for the late response, I've been researching the project, going over
> the source code and preparing the proposal. After a lot of thought, I've
> decided to go with the "Offloading to a separate process on the same host"
> project, mostly because I feel like I've reasonable background on this
> project, as I've worked on OpenMP, GPU Programming and have done coursework
> on compilers and operating systems. Yes, I am no longer a student. I
> recently graduated from the University of California, Irvine with a
> master's degree in Computer Engineering (About 3 months back) and I've
> recently joined Qualcomm as a firmware engineer. I realized that I have a
> lot of free time, that I mostly spend playing video games, and I've always
> wanted to get into open source development, so I thought this would be a
> good opportunity, given how much I use gcc for everything.
>

This sounds great.

First, please note that timing of the GSoC contributor application
deadline (on the upcoming Tuesday) is a bit unfortunate because of
Easter, many involved mentors have a long weekend (public holiday on
Friday or Monday or, like me, both).  So please even if you do not
receive any feedback, make sure to apply - and don't leave it until the
last day.  IIUC a proposal can be always updated later.

I'll have to admit that I read your proposal only quickly and it makes
sense.  I'd just like to point out that the VGPU part is really a second
(though perhaps much larger and interesting) part of the project, the
first part would be to simulate a CPU-like accelerator with a separate
memory.  But most of this work would be necessary for VGPU part too.
What is more, the VGPU part is likely to be hard, so if your time
constraints allow it and doing both is your goal, I'd suggest to apply
for an 350-hour (large) project.

I'll see if I can cough out any more feedback in time but as I wrote
above, generally it is good and don't wait - t least not with the
initial application.

Good luck!

Martin


> Why specifically this project -
> OpenMP's support for offloading to physical GPUs broadens the horizon for
> high-performance computing applications, the complexity of setting up such
> environments and the lack of adequate tooling for development and debugging
> can hinder productivity. The VGPU project directly addresses these
> challenges by providing a developer-friendly offloading target that
> emulates GPU execution on the host CPU, bridging the existing tooling gap
> and significantly enhancing developer productivity in the realm of parallel
> computing.
>
> Anyway, getting into the details of the project, from my understanding, the
> goals are -
> 1) To implement a virtual GPU (VGPU) environment that mirrors physical GPU
> architecture including support for different levels of parallelism (warp,
> thread block, etc.).
> 2) To enable the VGPU to serve as an offload target within the LLVM/OpenMP
> framework. This includes adding a host-ISA offloaded code generation mode
> that allows the compilation of OpenMP applications using GPU-specific paths
> and runtimes, facilitating a more accurate emulation of GPU environments.
> 3) To implement a plugin for libgomp that communicates with the libgomp
> offloading machinery to manage the execution of offloaded code in a new
> process, simulating the behavior of actual GPU devices.
> 4) To optimize the VGPU to ensure that OpenMP applications executed on it
> incur minimal performance overhead compared to native host execution,
> thereby making it a viable option for development and testing purposes.
>
> Here's a rough timeline (Based on the timeline on the gsoc website) -
> Pre-coding (Until May 27) -
> 1) Setting up a development environment including LLVM/OpenMP and necessary
> debugging tools.
> 2) Conducting thorough literature review on existing GPU simulation
> techniques and OpenMP offloading mechanisms.
>
> Week 1-3: Initial Infrastructure
> 1) Design VGPU architecture (simulate gpu parallel execution models (warps,
> blocks) and memory hierarchy (global, shared, private))
> 2) Implement the core vgpu infrastructure, like basic memory management.
>
> Week 4-6: Integration with LLVM/OpenMP and Host-ISA Offload Mode
> 1) Develop LLVM IR generation for VGPU target, thereby ensuring openMP
> directives can be compiled into vgpu-compatible code.
> 2) Add a new mode in the LLVM/OpenMP framework for generating offloaded
> code specifically for the VGPU target.
> 3) Get simple openMP applications to compile and execute on the VGPU.
>
> By Midterm evaluation, hopefully should have basic openmp applications
> offloaded on the VGPU.
>
> Week 7-9: Extending functionality and Implementing libgomp Plugin
> 1) Extend VGPU to support more functionality like loops, sections, parallel
> blocks.
> 2) Implement a plug-in for libgomp that interfaces with its offloading
> machinery.
> 3) Maybe look to 

Re: GSoC 2024 [Fortran - DO CONCURRENT] Seeking feedback/suggestions for project proposal

[Martin Jambor]

Hello Anuj,

On Thu, Mar 28 2024, Anuj Mohite wrote:
> Hi,
> I'm Anuj M, an undergraduate student interested in participating in GSoC
> 2024 with GCC. I would like to work on the project improving the DO
> CONCURRENT construct in the GFortran compiler.The current implementation in
> GFortran has limitations in handling locality clauses, supporting reduction
> operations, and parallelization strategies for DO CONCURRENT loops. So the
> proposal aims to address these limitations:

timing of the GSoC contributor application deadline (on the upcoming
Tuesday) is a bit unfortunate because of Easter, many involved mentors
have a long weekend (public holiday on Friday or Monday or, like me,
both).  So please even if you do not receive any more feedback, make
sure to apply - and don't leave it until the last day.  IIUC a proposal
can be always updated later.

I admit that I managed to have only a very quick look at your proposal
but it all looked good to me.

Good luck!

Martin

>
>1. Implementing locality clauses and ensuring correct handling of data
>dependencies.
>2. Supporting reduction operations in DO CONCURRENT loops.
>3. Developing parallelization strategies, including OpenMP-based
>parallelization and OpenMP offloading.
>
> I have added a detailed project proposal outlining the implementation
> approach, timeline, my relevant background, and experience.
>
> I would greatly appreciate feedback or suggestions from the GCC community
> regarding this project proposal.
>
> Best regards,
> Anuj M
>
> ## GCC, the GNU Compiler Collection - Google Summer Of Code 24 Proposal -
> Anuj Mohite
>
> Project: Fortran - DO CONCURRENT
>
> Abstract:
>
> The `DO CONCURRENT` construct, introduced in the Fortran 2018 standard,
> provides a mechanism to express parallelism in Fortran programs. However,
> fully leveraging its potential requires a systematic and comprehensive
> implementation within Fortran compilers. This proposal outlines a robust
> solution for implementing `DO CONCURRENT` support, encompassing parsing and
> handling of locality clauses, enabling reduction operations, and developing
> parallelization strategies utilising OpenMP.
> To ensure efficient parallel execution, performance optimization techniques
> will be employed. By facilitating efficient parallelization of `DO
> CONCURRENT` loops, this project aims to contribute to Fortran's continued
> performance in high-performance computing domains, further enhancing its
> capabilities in this crucial area.
>
> Current State of Feature:
>
> At present, the support for the `DO CONCURRENT` construct in the GFortran
> compiler is limited. The existing implementation only partially handles the
> locality clauses introduced in the Fortran 2018 standard, and it lacks
> support for reduction operations and parallelization strategies. As a
> result, the performance gains achievable through the `DO CONCURRENT`
> construct are not fully realised.
>
> The current implementation in GFortran involves a basic parser for the `DO
> CONCURRENT` construct and its locality clauses. However, the semantic
> analysis and code generation phases are incomplete, leading to incorrect
> handling of data dependencies and potential race conditions. Additionally,
> the compiler does not support reduction operations or any parallelization
> strategies for `DO CONCURRENT` loops, effectively executing them in a
> serial manner.
>
> Other Fortran compilers, such as those from NVIDIA's nvfortran and Intel's
> ifort, have implemented varying levels of support for `DO CONCURRENT`.
> However, their implementations often have limitations or restrictions, and
> their performance can vary depending on the specific workload and hardware
> architecture.
>
> Furthermore, as the Fortran language continues to evolve, with the upcoming
> Fortran 202x standard introducing additional features and enhancements
> related to the `DO CONCURRENT` construct, it is crucial for compilers to
> stay up-to-date and provide comprehensive support for these language
> features.
> Project Goals
>
> The primary goals of this project are:
>
> 1. Implement Locality Clauses:
>
> * Extend the GFortran compiler to support locality clauses specified in the
> Fortran 2018 standard for the `DO CONCURRENT` construct.
> * Include parsing, semantic analysis, and code generation phases to handle
> specified data dependencies correctly.
> * Modify the compiler's parser to recognize new syntax for `DO CONCURRENT`
> loops and locality clauses, constructing an accurate AST.
> * Enhance semantic analysis phase to perform data dependency analysis,
> loop-carried dependency analysis, and alias analysis.
> * Resolve data dependencies and identify potential parallelization
> opportunities.
>
> 2. Support Reduction Operations:
>
> * add support for reduction operations in the `DO CONCURRENT` construct, as
> introduced in the upcoming Fortran 202x standard.
> * Involve parsing reduction clauses, semantic analysis for 

Re: [PATCH] ipa: Avoid duplicate replacements in IPA-SRA transformation phase

[Martin Jambor]

Hello,

and ping, please.  (In my copy I have fixed the formatting issue spotted
by Jakub.)

Martin

On Fri, Mar 15 2024, Martin Jambor wrote:
> Hi,
>
> when the analysis part of IPA-SRA figures out that it would split out
> a scalar part of an aggregate which is known by IPA-CP to contain a
> known constant, it skips it knowing that the transformation part looks
> at IPA-CP aggregate results too and does the right thing (which can
> include doing the propagation in GIMPLE because that is the last
> moment the parameter exists).
>
> However, when IPA-SRA wants to split out a smaller non-aggregate out
> of an aggregate, which happens to be of the same size as a known
> scalar constant at the same offset, the transformation bit fails to
> recognize the situation, tries to do both splitting and constant
> propagation and in PR 111571 testcase creates a nonsensical call
> statement on which the call redirection then ICEs.
>
> Fixed by making sure we don't try to do two replacements of the same
> part of the same parameter.
>
> The look-up among replacements requires these are sorted and this
> patch just sorts them if they are not already sorted before each new
> look-up.  The worst number of sortings that can happen is number of
> parameters which are both split and have aggregate constants times
> param_ipa_max_agg_items (default 16).  I don't think complicating the
> source code to optimize for this unlikely case is worth it but if need
> be, it can of course be done.
>
> Bootstrapped and tested on x86_64-linux.  OK for master and eventually
> also the gcc-13 branch?
>
> Thanks,
>
> Martin
>
>
>
> gcc/ChangeLog:
>
> 2024-03-15  Martin Jambor  
>
>   PR ipa/111571
>   * ipa-param-manipulation.cc
>   (ipa_param_body_adjustments::common_initialization): Avoid creating
>   duplicate replacement entries.
>
> gcc/testsuite/ChangeLog:
>
> 2024-03-15  Martin Jambor  
>
>   PR ipa/111571
>   * gcc.dg/ipa/pr111571.c: New test.
> ---
>  gcc/ipa-param-manipulation.cc   | 16 
>  gcc/testsuite/gcc.dg/ipa/pr111571.c | 29 +
>  2 files changed, 45 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/ipa/pr111571.c
>
> diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
> index 3e0df6a6f77..4c6337cc563 100644
> --- a/gcc/ipa-param-manipulation.cc
> +++ b/gcc/ipa-param-manipulation.cc
> @@ -1525,6 +1525,22 @@ ipa_param_body_adjustments::common_initialization 
> (tree old_fndecl,
>replacement with a constant (for split aggregates passed
>by value).  */
>  
> +   if (split[parm_num])
> + {
> +   /* We must be careful not to add a duplicate
> +  replacement. */
> +   sort_replacements ();
> +   ipa_param_body_replacement *pbr =
> + lookup_replacement_1 (m_oparms[parm_num],
> +   av.unit_offset);
> +   if (pbr)
> + {
> +   /* Otherwise IPA-SRA should have bailed out.  */
> +   gcc_assert (AGGREGATE_TYPE_P (TREE_TYPE (pbr->repl)));
> +   continue;
> + }
> + }
> +
> tree repl;
> if (av.by_ref)
>   repl = av.value;
> diff --git a/gcc/testsuite/gcc.dg/ipa/pr111571.c 
> b/gcc/testsuite/gcc.dg/ipa/pr111571.c
> new file mode 100644
> index 000..2a4adc608db
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/ipa/pr111571.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2"  } */
> +
> +struct a {
> +  int b;
> +};
> +struct c {
> +  long d;
> +  struct a e;
> +  long f;
> +};
> +int g, h, i;
> +int j() {return 0;}
> +static void k(struct a l, int p) {
> +  if (h)
> +g = 0;
> +  for (; g; g = j())
> +if (l.b)
> +  break;
> +}
> +static void m(struct c l) {
> +  k(l.e, l.f);
> +  for (;; --i)
> +;
> +}
> +int main() {
> +  struct c n = {10, 9};
> +  m(n);
> +}
> -- 
> 2.44.0

Re: "GSoC"

[Martin Jambor]

Hello,

On Sun, Mar 24 2024, M Hamza Nadeem via Gcc wrote:
> Hi Sir / mam,
>
>
> I hope this email finds you well. As an enthusiastic contributor with a
> strong grasp of C/C++ and familiarity with Rust, I am eager to explore
> potential projects for Google Summer of Code (GSoC) 2024 within the GNU
> Compiler Collection (GCC) ecosystem.

we are delighted you found the prospect of contributing to GCC interesting.

>
> With my background in these languages and my passion for advancing compiler
> technology, I believe I could make significant contributions to various GCC
> projects.
>
> I would greatly appreciate any guidance on how to proceed further with
> project selection or any additional insights into the GCC projects relevant
> to my skill set.

Please look again at the "Before you apply" section of our GSoC page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you are
able to build, install and test GCC.  I strongly suggest that you also try
generating dumps of the IR of a simple compiled program and stepping through
some function during compilation in a debugger.

Afterwards, look at the suggested projects, try to identify the portion of GCC
source where it needs to be implemented and think about how.  Then email us
back to this mailing list describing your current plan together with any
technical questions you'd like to have answered to proceed further.  We'll be
happy to help.

Good luck,

Martin

Re: GSoC

[Martin Jambor]

On Sat, Mar 23 2024, koushiki khobare via Gcc wrote:
> Respected sir,
>
> I am Koushiki Khobare from India and currently a first year
> student(Computer Science Student) studying in Pune Institute of
> Computer Technology, Pune, Maharashtra. Recently I heard about GSoC
> and got very excited to explore it. I will be very much thankful to
> you if you provide me some guidance and help me to explore more. I
> have learnt C programming language. So I visited your projects and
> they were all amazing and quite interesting to work upon.

We are delighted you found contributing to GCC interesting.  

Please note that apart from C (and C++!) coding skills, most projects
require some rudimentary theoretical background in compilers.

> One of them
> I am thinking to explore is “Rust Front End”.So I will be grateful to
> work with all my mentors- Mr.Pierre-Emmaunel Patry, Mr. Philip Herron,
> Mr.Arthur Cohen, all being excellent in their works.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to them there as well.

> I will be so much
> of grateful if I get to know what actual skills do you expect from me
> apart from mentioned on website and guide me with what all do I need
> to do in my proposal.

The skills mentioned on the website
(i.e. https://gcc.gnu.org/wiki/SummerOfCode ) should be quite
sufficient.  I can only advise that you look at the "Before you apply"
section and take (most of) the steps described there.

> I request you to provide me some guidance with my proposal.

You need to select a particular project and make at least a few first
steps (again, at look at those described at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply ) yourself.  Then
we can help you to polish things up.

Good luck!

Martin Jambor

Re: Interest in Contributing to OpenACC Support & Code Offloading Projects for GSOC

[Martin Jambor]

Hello,

On Thu, Mar 21 2024, Soumya Ranjan via Gcc wrote:
> Hello,
>
> I hope this message finds you well. My name is Soumya Ranjan, and I hold a
> Bachelor's degree in Electrical Engineering and a Master's in Computer
> Engineering. I am currently working as a Firmware Engineer at Qualcomm
> Wireless R I recently discovered your organization and the exciting GSOC
> projects you are proposing, namely "Offloading to a separate process on the
> same host" and "Enhance OpenACC support." I am writing to express my
> enthusiastic interest in potentially contributing to either of these
> projects and to inquire about the next steps to formally apply or draft a
> proposal.

The above suggests you are no longer a full time student (but then your
email address indicates you might be :-) so I suppose you fulfill the
7.1.(a).iv clause of GSoC rules by being a "beginner to open source
software development."  If so, we are delighted that you decided to
start your FOSS journey with us.

>
> My academic journey was enriched with substantial coursework in operating
> systems and parallel computing, sparking a deep interest in efficient
> computational strategies and optimizations. My professional experience has
> further developed my skills in C/C++, offloading compilation, and
> inter-process communication. Given this foundation, I am confident in my
> capacity to make a meaningful contribution to either the project focused on
> enhancing debugging capabilities for offloaded code or the one aimed at
> filling the existing gaps in OpenACC support, depending on where my skills
> can be best utilized.
>
> I realize I am reaching out at a time when proposals are likely already
> underway. I apologize for this timing and am committed to diligently
> catching up. I've started to familiarize myself with the "Before You Apply"
> guidelines on your website to ensure I understand the necessary preparatory
> steps.
>
> Could you kindly advise if there are any additional specific steps I should
> follow or particular aspects of either project you would recommend focusing
> on in my proposal? The prospect of contributing to advancements in either
> domain is highly motivating to me, and I am keen to align my efforts with
> the project's most pressing needs.

The generic steps are listed in the "Before You Apply" guidelines. 

As far as the "Offloading to a separate process" project is concerned,
please have a look at a recent discussions in the mailing list archive,
specifically at
  - https://gcc.gnu.org/pipermail/gcc/2024-March/243462.html and
  - https://gcc.gnu.org/pipermail/gcc/2024-March/243478.html

As far as I can tell, the project on enhancing the OpenACC has not been
discussed yet.  I am not really familiar with OpenACC myself, so can
only give rudimentary advice.  First, I'd make sure that I know what the
routines/directives that need to be implemented do.  Second, I'd then
find some basic OpenACC testcase and do a similar experiment as
described in the email messages linked above (but perhaps with
-fdump-tree-all and not just -fdump-tree-optimize).  That should give
you an idea where to look next.  

Please feel free to ask here on the mailing list for help with any
specific technical issue or question you encounter.

> I am eager to learn more about how I can integrate into your team and
> contribute effectively. I believe this opportunity aligns perfectly with my
> professional aspirations and skills, and I am excited about the potential
> collaboration.

Given the timing, I'd focus on the proposal.  The key should be to
convince us that you have the ability to complete the project.
I.e. that you understand what needs to be done and have a rough idea - a
very rough but mostly correct idea - what and where needs to be changed
to do so.

Good luck!

Martin

>
> Thank you very much for considering my application. I look forward to the
> opportunity to further discuss how I can contribute to the success of your
> project.
>
> Warm regards,
> Soumya Ranjan

Re: [PATCH] tree-optimization/113727 - bogus SRA with BIT_FIELD_REF

[Martin Jambor]

Hello,

On Tue, Mar 19 2024, Richard Biener wrote:
> When SRA analyzes BIT_FIELD_REFs it handles writes and not byte
> aligned reads differently from byte aligned reads.  Instead of
> trying to create replacements for the loaded portion the former
> cases try to replace the base object while keeping the wrapping
> BIT_FIELD_REFs.  This breaks when we have both kinds operating
> on the same base object if there's no appearant overlap conflict
> as the conflict that then nevertheless exists isn't handled with.
> The fix is to enforce what I think is part of the design handling
> the former case - that only the full base object gets replaced
> and no further sub-objects are created within as otherwise
> keeping the wrapping BIT_FIELD_REF cannot work.  The patch
> enforces this within analyze_access_subtree.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> OK?

I agree this is the best thing to do.

Thanks,

Martin

>
> Thanks,
> Richard.
>
>   PR tree-optimization/113727
>   * tree-sra.cc (analyze_access_subtree): Do not allow
>   replacements in subtrees when grp_partial_lhs.
>
>   * gcc.dg/torture/pr113727.c: New testcase.
> ---
>  gcc/testsuite/gcc.dg/torture/pr113727.c | 26 +
>  gcc/tree-sra.cc |  3 ++-
>  2 files changed, 28 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr113727.c
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr113727.c 
> b/gcc/testsuite/gcc.dg/torture/pr113727.c
> new file mode 100644
> index 000..f92ddad5c8e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr113727.c
> @@ -0,0 +1,26 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target int32plus } */
> +
> +struct f {
> +  unsigned au : 5;
> +  unsigned f3 : 21;
> +} g_994;
> +
> +int main()
> +{
> +  struct f aq1 = {};
> +{
> +  struct f aq = {9, 5};
> +  struct f as = aq;
> +  for (int y = 0 ; y <= 4; y += 1)
> + if (as.au)
> +   {
> + struct f aa[5] = {{2, 154}, {2, 154}, {2, 154}, {2, 154}, {2, 154}};
> + as = aa[0];
> +   }
> +  aq1 = as;
> +}
> +  if (aq1.f3 != 0x9a)
> +__builtin_abort();
> +  return 0;
> +}
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index f8e71ec48b9..dbfae5e7fdd 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -2735,7 +2735,8 @@ analyze_access_subtree (struct access *root, struct 
> access *parent,
>  {
>hole |= covered_to < child->offset;
>sth_created |= analyze_access_subtree (child, root,
> -  allow_replacements && !scalar,
> +  allow_replacements && !scalar
> +  && !root->grp_partial_lhs,
>totally);
>  
>root->grp_unscalarized_data |= child->grp_unscalarized_data;
> -- 
> 2.35.3

[gcc r14-9559] ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:bf838884fac573b4902a21bb82d9b6f777e32cb9

commit r14-9559-gbf838884fac573b4902a21bb82d9b6f777e32cb9
Author: Martin Jambor 
Date:   Tue Mar 19 22:33:27 2024 +0100

ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.

Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.

The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code.  The pattern
matcher had a small bug which did not matter before
r10-917-g3b47da42de621c but did afterwards.

This patch changes the pattern matcher to match both of these cases.

gcc/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads 
from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a 
pointer
parameter, also recognize the case when pfn pointer is loaded in its
own BB.

gcc/testsuite/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* g++.dg/ipa/iinline-4.C: New test.
* g++.dg/ipa/pr108802.C: Likewise.

Diff:
---
 gcc/ipa-prop.cc  | 110 +--
 gcc/testsuite/g++.dg/ipa/iinline-4.C |  61 +++
 gcc/testsuite/g++.dg/ipa/pr108802.C  |  14 +
 3 files changed, 154 insertions(+), 31 deletions(-)

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index e22c4f78405..e8e4918d5a8 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -2500,7 +2500,9 @@ static tree
 ipa_get_stmt_member_ptr_load_param (gimple *stmt, bool use_delta,
HOST_WIDE_INT *offset_p)
 {
-  tree rhs, rec, ref_field, ref_offset, fld, ptr_field, delta_field;
+  tree rhs, fld, ptr_field, delta_field;
+  tree ref_field = NULL_TREE;
+  tree ref_offset = NULL_TREE;
 
   if (!gimple_assign_single_p (stmt))
 return NULL_TREE;
@@ -2511,35 +2513,53 @@ ipa_get_stmt_member_ptr_load_param (gimple *stmt, bool 
use_delta,
   ref_field = TREE_OPERAND (rhs, 1);
   rhs = TREE_OPERAND (rhs, 0);
 }
-  else
-ref_field = NULL_TREE;
-  if (TREE_CODE (rhs) != MEM_REF)
-return NULL_TREE;
-  rec = TREE_OPERAND (rhs, 0);
-  if (TREE_CODE (rec) != ADDR_EXPR)
-return NULL_TREE;
-  rec = TREE_OPERAND (rec, 0);
-  if (TREE_CODE (rec) != PARM_DECL
-  || !type_like_member_ptr_p (TREE_TYPE (rec), _field, _field))
+
+  if (TREE_CODE (rhs) == MEM_REF)
+{
+  ref_offset = TREE_OPERAND (rhs, 1);
+  if (ref_field && integer_nonzerop (ref_offset))
+   return NULL_TREE;
+}
+  else if (!ref_field)
 return NULL_TREE;
-  ref_offset = TREE_OPERAND (rhs, 1);
+
+  if (TREE_CODE (rhs) == MEM_REF
+  && TREE_CODE (TREE_OPERAND (rhs, 0)) == SSA_NAME
+  && SSA_NAME_IS_DEFAULT_DEF (TREE_OPERAND (rhs, 0)))
+{
+  rhs = TREE_OPERAND (rhs, 0);
+  if (TREE_CODE (SSA_NAME_VAR (rhs)) != PARM_DECL
+ || !type_like_member_ptr_p (TREE_TYPE (TREE_TYPE (rhs)), _field,
+ _field))
+   return NULL_TREE;
+}
+  else
+{
+  if (TREE_CODE (rhs) == MEM_REF
+ && TREE_CODE (TREE_OPERAND (rhs, 0)) == ADDR_EXPR)
+   rhs = TREE_OPERAND (TREE_OPERAND (rhs, 0), 0);
+  if (TREE_CODE (rhs) != PARM_DECL
+ || !type_like_member_ptr_p (TREE_TYPE (rhs), _field,
+ _field))
+   return NULL_TREE;
+}
 
   if (use_delta)
 fld = delta_field;
   else
 fld = ptr_field;
-  if (offset_p)
-*offset_p = int_bit_position (fld);
 
   if (ref_field)
 {
-  if (integer_nonzerop (ref_offset))
+  if (ref_field != fld)
return NULL_TREE;
-  return ref_field == fld ? rec : NULL_TREE;
 }
-  else
-return tree_int_cst_equal (byte_position (fld), ref_offset) ? rec
-  : NULL_TREE;
+  else if (!tree_int_cst_equal (byte_position (fld), ref_offset))
+return NULL_TREE;
+
+  if (offset_p)
+*offset_p = int_bit_position (fld);
+  return rhs;
 }
 
 /* Returns t

Re: Interest in GSoC Project (offloading to a separate process on the same host)

[Martin Jambor]

Hello Pranil,

We are delighted you found contributing to GCC interesting.

On Fri, Mar 15 2024, PRANIL DEY via Gcc wrote:
> Hello GCC Community,
>
> I am Pranil Dey, a 4th year undergraduate student of the Indian Institute
> of Technology Kharagpur currently pursuing a Bachelor's Degree in Computer
> Science and Engineering. I am interested in contributing to the GCC
> projects under GSoC, specifically the projects : "Offloading to a separate
> process on the same host" and "Improve nothrow detection in GCC".
> I have worked on inter process communication in college operating systems
> projects which have helped me understand more about shared memory, pipes
> and multithreading concepts. I have also taken compiler design theory and
> laboratory courses as a part of my institute curriculum. In the lab we
> designed a Tiny-C compiler (a subset of GCC). Although I have no experience
> with big projects like GCC, I have built the codebase and am currently
> trying to understand it further.

Great, you seem to be very well prepared!

> I would like some pointers to start
> understanding and contributing to these projects along with any
> helpful resources/reading material for delving deeper into the relevant
> topic. Any guidance on proposal formulation will also be appreciated
> greatly.

As far as the offloading to a separate process project is concerned, we
have had a brief discussion on this mailing list in the recent past,
have a look especially at
https://gcc.gnu.org/pipermail/gcc/2024-March/243462.html and
https://gcc.gnu.org/pipermail/gcc/2024-March/243478.html

As far as the nothrow detection project is concerned, let me quote Honza
Hubička from an email which, probably by mistake, did not reach the
mailing list:

--
GCC EH works in a way that it marks statements that can possibly throw
(these can be calls or non-call exceptions) and assigns them to EH
regions.  EH regions are organized into a tree structure which describes
what types are caught and handled.

This data structure is in except.h / except.cc and can be dumped
before/after every pass (I believe iwth -fdump-tree-all-details)

For optimization we have two predicates - can_throw_internal and
can_throw_external which are used to detect notrhow functions and if
function is notrhow we can save EH tables and optimize EH hadnling code
(especialy EH cleanup regions calling implicit destructors that are
quite frequent).

What we miss the ability to track type of a given exception and detect
that given function handles all exceptions that it can possibly receive.
As a result such code leads to unnecesary cleanups later.

So the work is to make middle-end aware of it - is probably quite
easily detectable from calls to __cxa_throw which takes the type as
parameter.  Then we need to add propagation which will understand what
kind of exceptions are rethrown which will let us to deterine list of
all types possibly thrown by the function.

So I think good start is to look into the data-structure EH is
represented and look into detecting types of __cxa_throw.

The nothrow discovery currently lives in pure-const pass and is very
simple minded: if something in function apsses can_throw_external then
function can throw.  So in the next step the propgation will need to be
added here.
--

Hope this help, if you have any specific issues you'd like to help with,
certainly feel free to ask here again.

Good luck!

Martin Jambor

[PATCH] ipa: Avoid duplicate replacements in IPA-SRA transformation phase

[Martin Jambor]

Hi,

when the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the propagation in GIMPLE because that is the last
moment the parameter exists).

However, when IPA-SRA wants to split out a smaller non-aggregate out
of an aggregate, which happens to be of the same size as a known
scalar constant at the same offset, the transformation bit fails to
recognize the situation, tries to do both splitting and constant
propagation and in PR 111571 testcase creates a nonsensical call
statement on which the call redirection then ICEs.

Fixed by making sure we don't try to do two replacements of the same
part of the same parameter.

The look-up among replacements requires these are sorted and this
patch just sorts them if they are not already sorted before each new
look-up.  The worst number of sortings that can happen is number of
parameters which are both split and have aggregate constants times
param_ipa_max_agg_items (default 16).  I don't think complicating the
source code to optimize for this unlikely case is worth it but if need
be, it can of course be done.

Bootstrapped and tested on x86_64-linux.  OK for master and eventually
also the gcc-13 branch?

Thanks,

Martin



gcc/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::common_initialization): Avoid creating
duplicate replacement entries.

gcc/testsuite/ChangeLog:

2024-03-15  Martin Jambor  

PR ipa/111571
* gcc.dg/ipa/pr111571.c: New test.
---
 gcc/ipa-param-manipulation.cc   | 16 
 gcc/testsuite/gcc.dg/ipa/pr111571.c | 29 +
 2 files changed, 45 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr111571.c

diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipulation.cc
index 3e0df6a6f77..4c6337cc563 100644
--- a/gcc/ipa-param-manipulation.cc
+++ b/gcc/ipa-param-manipulation.cc
@@ -1525,6 +1525,22 @@ ipa_param_body_adjustments::common_initialization (tree 
old_fndecl,
 replacement with a constant (for split aggregates passed
 by value).  */
 
+ if (split[parm_num])
+   {
+ /* We must be careful not to add a duplicate
+replacement. */
+ sort_replacements ();
+ ipa_param_body_replacement *pbr =
+   lookup_replacement_1 (m_oparms[parm_num],
+ av.unit_offset);
+ if (pbr)
+   {
+ /* Otherwise IPA-SRA should have bailed out.  */
+ gcc_assert (AGGREGATE_TYPE_P (TREE_TYPE (pbr->repl)));
+ continue;
+   }
+   }
+
  tree repl;
  if (av.by_ref)
repl = av.value;
diff --git a/gcc/testsuite/gcc.dg/ipa/pr111571.c 
b/gcc/testsuite/gcc.dg/ipa/pr111571.c
new file mode 100644
index 000..2a4adc608db
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr111571.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2"  } */
+
+struct a {
+  int b;
+};
+struct c {
+  long d;
+  struct a e;
+  long f;
+};
+int g, h, i;
+int j() {return 0;}
+static void k(struct a l, int p) {
+  if (h)
+g = 0;
+  for (; g; g = j())
+if (l.b)
+  break;
+}
+static void m(struct c l) {
+  k(l.e, l.f);
+  for (;; --i)
+;
+}
+int main() {
+  struct c n = {10, 9};
+  m(n);
+}
-- 
2.44.0

Re: GSoC

[Martin Jambor]

Hello,

On Tue, Mar 12 2024, Abhinav Gupta wrote:
> Hi! Thank you for replying to my request!
> I looked at all the links you provided in the reply and read the
> paper cited on the GCC page for GSoC. I also looked into the rust
> frontend project during this time, and the Offloading project
> interests me more, so I will focus solely on it in the remaining seven
> days before the deadline for GSoC application submission.

AFAIU, in five days (from now) the application period *opens*, the
deadline is 2nd April.  Still it is good idea not to lose any time.

> Are there other resources I can look at to better understand the whole
> process? Reading the git commit on the website is proving to be very
> slow. I think the git commit about Intel MIC would be like a
> "template" in loose terms to implement the host-ISA mode at least, but
> for the libgomp plugin, I need a better understanding.

You need to understand how OpenMP programs are internally represented.

Look at the following (hopefully correct, at least as long as you try it
on a system without any Offloading enabled) simple testcase for OpenMP
target construct:

--
#include 

volatile int v = 1;

int main (int argc, char **argv)
{
  int i = v;

#pragma omp target map(to:i)
  {
printf ("OpenMP target hello world, i is: %i\n", i);
  }

  return 0;
}
--

and compile it with:

  gcc -fopenmp omptgt-hello.c -O2 -fdump-tree-optimized

and then look at the generated optimized dump.  This should give you an
idea how OpenMP regions are internally represented (as outlined
functions) and how calls into libgomp, the run-time library doing a lot
of the magic, look like.

You can try to do more similar exercises with more OpenMP testcase which
you can find in sub-directory libgomp/testsuite/libgomp.c of in the GCC
repository.

And then you should perhaps have a look into libgomp itself (you'll find
it in libgomp sub-directory) how GOMP_target_ext is implemented - though
don't worry if you don't understand many of the details, it is complex
stuff.  At this point hopefully more of the contents of the Offloading
wiki page will make sense.

Again, ask on the mailing list if you have any specific questions.

Good luck,

Martin

> Thanking you
> Abhinav
>
>
> On Thu, 7 Mar 2024 at 20:37, Martin Jambor  wrote:
>>
>> Hello,
>>
>> On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
>> > Dear GCC Community,
>> > I hope this email finds you well. My name is Abhinav Gupta. I am a
>> > 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
>> > computer science and engineering. I am writing to express my interest
>> > in contributing to the GCC project under GSoC.
>>
>> We are very happy that you find contributing to GCC interesting.
>>
>> > I am interested in two projects - Offloading to a separate process on
>> > the same host, I am already working in parallel computing,
>> > specifically parallelising tensor algorithms using various techniques
>> > as part of my research project at IIT Tirupati. Although this is not
>> > directly related to compilers, I will be able to get going with the
>> > project quickly.
>>
>> I'd personally very much like to see this project implemented.  There is
>> a lot of information on offloading at
>> https://gcc.gnu.org/wiki/Offloading
>>
>> To give you a bit more context where the idea comes from, it was first
>> thought of in email thread starting with
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603984.html and
>> the patch that was "scrubbed" from the email archive eventually became
>> commit
>> https://gcc.gnu.org/cgit/gcc/commit/?id=e4cba49413ca429dc82f6aa2e88129ecb3fdd943
>>
>> I hope these pointers will further help help you find out where to look
>> when planning the project.  If you need more help, please feel free to
>> ask (I'm CCing Thomas who then is perhaps best placed to answer).
>>
>> > The second project is Rust Front-End - both the BIR location support
>> > and rustc testsuite adapter are of interest to me,
>>
>> Please note that Rust-GCC projects are a bit special in the sense that
>> they are often discussed primarily on Zulip of the gcc-rust team:
>>
>> https://gcc-rust.zulipchat.com/
>>
>> So you may want to reach out to them there as well.
>>
>> > having worked on
>> > compiler front ends as part of my college's compiler design course
>> > combined with my experience in working with large libraries written in
>> > C++ (such as CTF) I be

[gcc r14-9403] ipa: Avoid excessive removing of SSAs (PR 113757)

[Martin Jambor via Gcc-cvs]

https://gcc.gnu.org/g:54e505d0446f86b7ad383acbb8e5501f20872b64

commit r14-9403-g54e505d0446f86b7ad383acbb8e5501f20872b64
Author: Martin Jambor 
Date:   Sat Mar 9 00:47:22 2024 +0100

ipa: Avoid excessive removing of SSAs (PR 113757)

PR 113757 shows that the code which was meant to debug-reset and
remove SSAs defined by LHSs of calls redirected to
__builtin_unreachable can trigger also when speculative
devirtualization creates a call to a noreturn function (and since it
is noreturn, it does not bother dealing with its return value).

What is more, it seems that the code handling this case is not really
necessary.  I feel slightly idiotic about this because I have a
feeling that I added it because of a failing test-case but I can
neither find the testcase nor a reason why the code in
cgraph_edge::redirect_call_stmt_to_callee would not be sufficient (it
turns the SSA name into a default-def, a bit like IPA-SRA, but any
code dominated by a call to a noreturn is not dangerous when it comes
to its side-effects).  So this patch just removes the handling.

gcc/ChangeLog:

2024-02-07  Martin Jambor  

PR ipa/113757
* tree-inline.cc (redirect_all_calls): Remove code adding SSAs to
id->killed_new_ssa_names.

gcc/testsuite/ChangeLog:

2024-02-07  Martin Jambor  

PR ipa/113757
* g++.dg/ipa/pr113757.C: New test.

Diff:
---
 gcc/testsuite/g++.dg/ipa/pr113757.C | 14 ++
 gcc/tree-inline.cc  | 14 ++
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/g++.dg/ipa/pr113757.C 
b/gcc/testsuite/g++.dg/ipa/pr113757.C
new file mode 100644
index 000..885d4010a10
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr113757.C
@@ -0,0 +1,14 @@
+// { dg-do compile }
+// { dg-options "-O2 -fPIC" }
+// { dg-require-effective-target fpic }
+
+long size();
+struct ll {  virtual int hh();  };
+ll  *slice_owner;
+int ll::hh() { __builtin_exit(0); }
+int nn() {
+  if (size())
+return 0;
+  return slice_owner->hh();
+}
+int (*a)() = nn;
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index f0a067f5812..eebcea8a029 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2984,23 +2984,13 @@ redirect_all_calls (copy_body_data * id, basic_block bb)
   gimple *stmt = gsi_stmt (si);
   if (is_gimple_call (stmt))
{
- tree old_lhs = gimple_call_lhs (stmt);
  struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
  if (edge)
{
  if (!id->killed_new_ssa_names)
id->killed_new_ssa_names = new hash_set (16);
- gimple *new_stmt
-   = cgraph_edge::redirect_call_stmt_to_callee (edge,
-   id->killed_new_ssa_names);
- if (old_lhs
- && TREE_CODE (old_lhs) == SSA_NAME
- && !gimple_call_lhs (new_stmt))
-   /* In case of IPA-SRA removing the LHS, the name should have
-  been already added to the hash.  But in case of redirecting
-  to builtin_unreachable it was not and the name still should
-  be pruned from debug statements.  */
-   id->killed_new_ssa_names->add (old_lhs);
+ cgraph_edge::redirect_call_stmt_to_callee (edge,
+   id->killed_new_ssa_names);
 
  if (stmt == last && id->call_stmt && maybe_clean_eh_stmt (stmt))
gimple_purge_dead_eh_edges (bb);

[PATCH] ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

[Martin Jambor]

Hi,

Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.

Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.

The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code.  The pattern
matcher had a small bug which did not matter before
r10-917-g3b47da42de621c but did afterwards.

This patch changes the pattern matcher to match both of these cases.

Special thanks to the Linaro automated checker of patches which
reported that the earlier version of my PR 108802 fix was not working
on Aarch64 which in turn made me discover PR 114254.

The patch has passed bootstrap and testing on x86_64-linux,
aarch64-linux and ppc64-linux and I also LTO bootstrap on x86_64-linux.

I understand we have been living with these deficiencies for a while now
but both are technically regressions.  If Honza agrees (and manages to
review the patch quickly), I'm fine with pushing them to master now but
I can also wait until the next stage 1.

Thanks,

Martin


gcc/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a pointer
parameter, also recognize the case when pfn pointer is loaded in its
own BB.

gcc/testsuite/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* g++.dg/ipa/iinline-4.C: New test.
* g++.dg/ipa/pr108802.C: Likewise.
---
 gcc/ipa-prop.cc  | 110 +++
 gcc/testsuite/g++.dg/ipa/iinline-4.C |  61 +++
 gcc/testsuite/g++.dg/ipa/pr108802.C  |  14 
 3 files changed, 154 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/iinline-4.C
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr108802.C

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index e22c4f78405..e8e4918d5a8 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -2500,7 +2500,9 @@ static tree
 ipa_get_stmt_member_ptr_load_param (gimple *stmt, bool use_delta,
HOST_WIDE_INT *offset_p)
 {
-  tree rhs, rec, ref_field, ref_offset, fld, ptr_field, delta_field;
+  tree rhs, fld, ptr_field, delta_field;
+  tree ref_field = NULL_TREE;
+  tree ref_offset = NULL_TREE;
 
   if (!gimple_assign_single_p (stmt))
 return NULL_TREE;
@@ -2511,35 +2513,53 @@ ipa_get_stmt_member_ptr_load_param (gimple *stmt, bool 
use_delta,
   ref_field = TREE_OPERAND (rhs, 1);
   rhs = TREE_OPERAND (rhs, 0);
 }
+
+  if (TREE_CODE (rhs) == MEM_REF)
+{
+  ref_offset = TREE_OPERAND (rhs, 1);
+  if (ref_field && integer_nonzerop (ref_offset))
+   return NULL_TREE;
+}
+  else if (!ref_field)
+return NULL_TREE;
+
+  if (TREE_CODE (rhs) == MEM_REF
+  && TREE_CODE (TREE_OPERAND (rhs, 0)) == SSA_NAME
+  && SSA_NAME_IS_DEFAULT_DEF (TREE_OPERAND (rhs, 0)))
+{
+  rhs = TREE_OPERAND (rhs, 0);
+  if (TREE_CODE (SSA_NAME_VAR (rhs)) != PARM_DECL
+ || !type_like_member_ptr_p (TREE_TYPE (TREE_TYPE (rhs)), _field,
+ _field))
+   return NULL_TREE;
+}
   else
-ref_field = NULL_TREE;
-  if (TREE_CODE (rhs) != MEM_REF)
-return NULL_TREE;
-  rec = TREE_OPERAND (rhs, 0);
-  if (TREE_CODE (rec) != ADDR_EXPR)
-return NULL_TREE;
-  rec = TREE_OPERAND (rec, 0);
-  if (TREE_CODE (rec) != PARM_DECL
-  || !type_like_member_ptr_p (TREE_TYPE (rec), _field, _field))
-return NULL_TREE;
-  ref_offset = TREE_OPERAND (rhs, 1);
+{
+  if (TREE_CODE (rhs) == MEM_REF
+ && TREE_CODE (TREE_OPERAND (rhs, 0)) == ADDR_EXPR)
+   rhs = TREE_OPERAND (TREE_OPERAND (rhs, 0), 0);
+  if (TREE_CODE (rhs) != PARM_DECL
+ || !type_like_member_ptr_p (TREE_TYPE (rhs), _field,
+ _field))
+   return NULL_TREE;
+}
 
   if (use_delta)
 fld = delta_field;
   else
 fld = ptr_field;
-  if (offset_p)
-*offset_p = int_bit_position (fld);
 
   if (ref_field)
 {
-  if (integer_nonzerop (ref_offset))
+  if (ref_field != fld)
return NULL_TREE;
-  return ref_field == fld ? rec : NULL_

Re: GSoC

[Martin Jambor]

Hello,

On Wed, Mar 06 2024, Abhinav Gupta via Gcc wrote:
> Dear GCC Community,
> I hope this email finds you well. My name is Abhinav Gupta. I am a
> 3rd-year student at IIT Tirupati pursuing a bachelor's degree in
> computer science and engineering. I am writing to express my interest
> in contributing to the GCC project under GSoC.

We are very happy that you find contributing to GCC interesting.

> I am interested in two projects - Offloading to a separate process on
> the same host, I am already working in parallel computing,
> specifically parallelising tensor algorithms using various techniques
> as part of my research project at IIT Tirupati. Although this is not
> directly related to compilers, I will be able to get going with the
> project quickly.

I'd personally very much like to see this project implemented.  There is
a lot of information on offloading at
https://gcc.gnu.org/wiki/Offloading

To give you a bit more context where the idea comes from, it was first
thought of in email thread starting with
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603984.html and
the patch that was "scrubbed" from the email archive eventually became
commit
https://gcc.gnu.org/cgit/gcc/commit/?id=e4cba49413ca429dc82f6aa2e88129ecb3fdd943

I hope these pointers will further help help you find out where to look
when planning the project.  If you need more help, please feel free to
ask (I'm CCing Thomas who then is perhaps best placed to answer).

> The second project is Rust Front-End - both the BIR location support
> and rustc testsuite adapter are of interest to me,

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to them there as well.

> having worked on
> compiler front ends as part of my college's compiler design course
> combined with my experience in working with large libraries written in
> C++ (such as CTF) I believe that these two projects are something that
> I can do.

You seem to be quite ready!

>
> Proposed Timeline:
> I can start working as soon as my end-semester exams finish, i.e. 9th
> May 2024, and continue to work for however long it requires me to
> complete the project.
> Week 1-2 -> Knowing the existing code and understanding how it works.

Right, but please try to do a bit of this, at least on the high level,
also now when preparing the proposal.  There will be lots to learn in
the first weeks even so.  Mainly because...

> Week 3-8 -> Working on the implementation of whichever project we
> decide to move forward with
> Week 9-12 -> Testing and creating understandable documentation for the same.
>
> This is a very rough timeline,

...eventually the milestones in the application will have to be more
specific, mainly to demonstrate you have basic understanding of the
proposed project.

> and I will refine it further as we
> discuss the project idea. This email is more of a call for guidance
> than an application, and I would appreciate any feedback you give me.

This is a very good start.

Good luck!

Martin

Re: About gsoc

[Martin Jambor]

Hello,

On Mon, Mar 04 2024, mokshagnareddyc--- via Gcc wrote:
> Hello sir/mam
> I am mokshagna reddy from Mahindra university and i am currently in my
> second year of under graduation in Btech artificial intelligence i had
> intrest in your organization and i know programming languages like c,
> c++,python how can i contribute from now and can u send details about
> the project.

We are delighted you found contributing to GCC interesting.

Please note that apart from C/C++ coding skills, most projects require
some rudimentary theoretical background in compilers.

Please look again at the "Before you apply" section of our GSoC page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC.  I strongly suggest that you
also try generating dumps of the IR of a simple compiled program and
stepping through some function during compilation in a debugger.

Afterwards, look at the suggested projects, try to identify the portion
of GCC source where it needs to be implemented and think about how.
Then email us back to this mailing list describing your current plan
together with any technical questions you'd like to have answered to
proceed further.  We'll be happy to help.

Good luck,

Martin

Re: [PATCH] ipa: Avoid excessive removing of SSAs (PR 113757)

[Martin Jambor]

Hello,

and ping please.

Martin


On Thu, Feb 08 2024, Martin Jambor wrote:
> Hi,
>
> PR 113757 shows that the code which was meant to debug-reset and
> remove SSAs defined by LHSs of calls redirected to
> __builtin_unreachable can trigger also when speculative
> devirtualization creates a call to a noreturn function (and since it
> is noreturn, it does not bother dealing with its return value).
>
> What is more, it seems that the code handling this case is not really
> necessary.  I feel slightly idiotic about this because I have a
> feeling that I added it because of a failing test-case but I can
> neither find the testcase nor a reason why the code in
> cgraph_edge::redirect_call_stmt_to_callee would not be sufficient (it
> turns the SSA name into a default-def, a bit like IPA-SRA, but any
> code dominated by a call to a noreturn is not dangerous when it comes
> to its side-effects).  So this patch just removes the handling.
>
> Bootstrapped and tested on x86_64-linux and ppc64le-linux.  I have also
> LTO-bootstrapped and LTO-profilebootstrapped the patch on x86_64-linux.
>
> OK for master?
>
> Thanks,
>
> Martin
>
>
> gcc/ChangeLog:
>
> 2024-02-07  Martin Jambor  
>
>   PR ipa/113757
>   * tree-inline.cc (redirect_all_calls): Remove code adding SSAs to
>   id->killed_new_ssa_names.
>
> gcc/testsuite/ChangeLog:
>
> 2024-02-07  Martin Jambor  
>
>   PR ipa/113757
>   * g++.dg/ipa/pr113757.C: New test.
> ---
>  gcc/testsuite/g++.dg/ipa/pr113757.C | 14 ++
>  gcc/tree-inline.cc  | 14 ++
>  2 files changed, 16 insertions(+), 12 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/ipa/pr113757.C
>
> diff --git a/gcc/testsuite/g++.dg/ipa/pr113757.C 
> b/gcc/testsuite/g++.dg/ipa/pr113757.C
> new file mode 100644
> index 000..885d4010a10
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ipa/pr113757.C
> @@ -0,0 +1,14 @@
> +// { dg-do compile }
> +// { dg-options "-O2 -fPIC" }
> +// { dg-require-effective-target fpic }
> +
> +long size();
> +struct ll {  virtual int hh();  };
> +ll  *slice_owner;
> +int ll::hh() { __builtin_exit(0); }
> +int nn() {
> +  if (size())
> +return 0;
> +  return slice_owner->hh();
> +}
> +int (*a)() = nn;
> diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
> index 75c10eb7dfc..cac41b4f031 100644
> --- a/gcc/tree-inline.cc
> +++ b/gcc/tree-inline.cc
> @@ -2984,23 +2984,13 @@ redirect_all_calls (copy_body_data * id, basic_block 
> bb)
>gimple *stmt = gsi_stmt (si);
>if (is_gimple_call (stmt))
>   {
> -   tree old_lhs = gimple_call_lhs (stmt);
> struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
> if (edge)
>   {
> if (!id->killed_new_ssa_names)
>   id->killed_new_ssa_names = new hash_set (16);
> -   gimple *new_stmt
> - = cgraph_edge::redirect_call_stmt_to_callee (edge,
> - id->killed_new_ssa_names);
> -   if (old_lhs
> -   && TREE_CODE (old_lhs) == SSA_NAME
> -   && !gimple_call_lhs (new_stmt))
> - /* In case of IPA-SRA removing the LHS, the name should have
> -been already added to the hash.  But in case of redirecting
> -to builtin_unreachable it was not and the name still should
> -be pruned from debug statements.  */
> - id->killed_new_ssa_names->add (old_lhs);
> +   cgraph_edge::redirect_call_stmt_to_callee (edge,
> + id->killed_new_ssa_names);
>  
> if (stmt == last && id->call_stmt && maybe_clean_eh_stmt (stmt))
>   gimple_purge_dead_eh_edges (bb);
> -- 
> 2.43.0

Re: GSoC 2024 Expression of interes

[Martin Jambor]

Hello,

On Wed, Feb 28 2024, Aditya Ballaki via Gcc wrote:
> Hi Team,
>
> I'm an incoming graduate student in Computer Engineering at Cornell
> University, and I'm keen on participating in GSOC by contributing to
> open-source projects before starting my graduate program.

Wonderful, welcome!

> Specifically, I'm interested in working on the Rust GCC compiler.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to gcc-rust developers there there as well.

> While I haven't made direct open-source contributions before, I'm
> quite familiar with Rust. I've also gained experience with C/C++
> through various projects involving low-level hardware programming and
> video game development. Moreover, I've worked with several other tech
> stacks and production-level code during my internships and research
> endeavours.
>
> Please let me know if it's appropriate for me to reach out to any of
> the listed mentors (Pierre-Emmanuel Patry, Philip Herron, Arthur
> Cohen) to discuss the project further.

It is, but I'd primarily suggest the zulip link given above.

Good luck!

Martin

Re: GSOC

[Martin Jambor]

Hello,

On Tue, Feb 27 2024, Pratush Rai via Gcc wrote:
> I want to work on the Rust Front End project as per the idea list. I am a
> rust compiler contributor and want to start contributing to gcc.
> I need some guidance on how to start.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So you may want to reach out to gcc-rust developers there there as well.

Apart from this, I can only point you to
https://gcc.gnu.org/wiki/SummerOfCode and specifically to
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains
some of the steps you can take to familiarize yourself with our code
base.

Good luck!

Martin Jambor

Re: Participation In GSoC 2024

[Martin Jambor]

Hello,

On Fri, Feb 23 2024, Mohd Kashif via Gcc wrote:
> Hey Sir/Madam,
> I want to participate in gsoc 2024 but I don't have any experience in it.
> Please be my mentor in this and help me to deliver the best project from my
> side .

We are delighted you found contributing to GCC interesting.  Please have
a look at https://gcc.gnu.org/wiki/SummerOfCode and specifically at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains
some of the steps you can take to familiarize yourself with our code
base and other initial steps to take.

Good luck,

Martin Jambor

Re: Contributor to the GSoC of 2024

[Martin Jambor]

Hello,

On Thu, Feb 22 2024, Suraj Kadapa via Gcc wrote:
> Hello,
>
> I am an undergraduate student with an extensive experience in computers
> from an early age, but most of my work has been limited to arduinos, and
> raspberry pi's. I have been intrigued with compilers, architecture and low
> level programming in the past few years. I have experience with ARM
> assembly and a little bit of x86 too. I have worked towards building
> bootloaders and teaching it to my fellow peers too. I've constructed a
> process virtual machine modeled after the LC-3 architecture and am
> presently focused on developing a basic emulator for RISC-V. Both of the
> previously mentioned projects are being done in C, and I have extensive
> experience in C. I really want to know how the GNU Compiler collection
> works under the hood and this is a really good opportunity for me to
> explore and learn.

We are delighted you found contributing to GCC interesting.  The above
is impressive but you may want to also look into some rudimentary
theoretical background in the area of compilers and compiler
optimizations, at least you need to understand the term "intermediate
representation" (IR) - sometimes also called "intermediate language"
(IL).  Most of GCC is written in C++, but that should not be an obstacle
for an experienced C programmer.

>
> Please reach out to me on what needs to be done to be accepted as a
> contributor to the GSoC program under the GNU organization,

The first steps are described in the "Before you apply" section of the
GSoC wiki page: https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply

> I would love to
> work on any of the projects mentioned in the wiki(would prefer some easy
> ones though, since I am not that deep yet).

Well, you will have to be the one to pick one.  Given your interests,
I'd recommend looking at "Offloading to a separate process on the same
host" and (recently added) "Implement structured dumping of GENERIC."
But don't let me discourage you looking at Fortran or any of the others
if you think that could be your thing.

>
> My github will be linked below, and I hope to hear from you soon!
> https://github.com/surajkadapa
>
> This is my first time writing for the GSoC program, so I am not really sure
> if this is how you reach out to organizations in this capacity. Please
> excuse any potential oversights as I navigate this process.
>

So far you have done the right thing.  Build GCC from source, try to
make some sense out of the source on the high level, pick a projet and
start thinking what parts would need changing and roughly how to
implement. If you have specific questions with the above, feel free to
ask on this mailing list or on IRC.

Good luck!

Martin

Re: getting start with GSoC

[Martin Jambor]

Hello,

On Fri, Feb 16 2024, Nada Elsayed via Gcc wrote:
> Hello All,
> I am Nada Elsayed, A fresh graduate from computer engineering at Cairo
> University.

welcome, we are delighted you found contributing to GCC interesting.

> I have good knowledge in C/C++, and a basic knowledge in compilers. als I
> am interested in contributing to the GCC this year; I am interested in 
> "*Extend
> the static analysis pass" *projects

Any particular one?

> or "*Improve nothrow detection in GCC" project*.*
>
> Till now I have built the code and I am trying to understand it more.

Good, this is the all-important first step.

> So what should I do now?

"Trying to understand it more" is exactly the correct thing to.  You
also need to locate which of the bits within GCC are relevant to the
project(s) you are interested in and start thinking what and where needs
to be changed in order to implement it.

If you have specific questions as you go about it, feel free to ask on
this mailing list or on IRC.

> Also, are bugs in https://gcc.gnu.org/wiki/EasyHacks good
> beginning or not?

The page itself is unfortunately very outdated.  However, the link to
the bugzilla search near its top might still be useful.

While it definitely helps, we do not strictly require applicants to do
any "easy hacks" or patch submissions prior to application.  The main
reason is that there are not as many opportunities for truly easy fixes
and improvements as other projects might have.  Still, feel free to
pursue one, it can only help!

Good luck!

Martin

GCC has been accepted as GSoC 2024 mentoring organization

[Martin Jambor]

Hello everyone,

I am pleased that I can announce that we have been accepted to be a GSoC
mentoring organization also in 2024!.

This also means that students are now really starting to look at our
idea page and so if anyone wants to add a project, it is still possible
but we should not delay it much longer.

Thanks to everyone who helped me with this so far. I am very happy that
we'll get this chance to attract new contributors this year too.

Martin



On Mon, Jan 15 2024, Martin Jambor wrote:
> Hello,
>
> another year has passed, Google has announced there will be again Google
> Summer of Code (GsoC) in 2024 and the deadline for organizations to
> apply is already approaching (February 6th).  I'd like to volunteer to
> be the main org-admin for GCC again but let me know if you think I
> shouldn't or that someone else should or if you want to do it instead.
> Otherwise I'll assume that I will and I hope that I can continue to rely
> on David Edelsohn and Thomas Schwinge to back me up and help me with
> some decision making along the way as my co-org-admins.
>
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

GCC has been accepted as GSoC 2024 mentoring organization

[Martin Jambor]

Hello everyone,

I am pleased that I can announce that we have been accepted to be a GSoC
mentoring organization also in 2024!.

This also means that students are now really starting to look at our
idea page and so if anyone wants to add a project, it is still possible
but we should not delay it much longer.

Thanks to everyone who helped me with this so far. I am very happy that
we'll get this chance to attract new contributors this year too.

Martin



On Mon, Jan 15 2024, Martin Jambor wrote:
> Hello,
>
> another year has passed, Google has announced there will be again Google
> Summer of Code (GsoC) in 2024 and the deadline for organizations to
> apply is already approaching (February 6th).  I'd like to volunteer to
> be the main org-admin for GCC again but let me know if you think I
> shouldn't or that someone else should or if you want to do it instead.
> Otherwise I'll assume that I will and I hope that I can continue to rely
> on David Edelsohn and Thomas Schwinge to back me up and help me with
> some decision making along the way as my co-org-admins.
>
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

[PATCH] ipa: Create indirect call edges also for lambdas

[Martin Jambor]

Hi,

Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, this code expects the member pointers to be structures
passed by value.  In PR 108802 it turned out that for lambdas these
are passed by reference.  This patch adjusts the code for that so that
small lambdas are also inlineable without depending on early inlining.

Bootstrapped and LTO bootstrapped on x86_64-linux.  This is technically
a regression against GCC 10.  OK for master even now?

Thanks,

Martin


gcc/ChangeLog:

2024-02-20  Martin Jambor  

PR ipa/108802
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Also recognize
loads from a pointer parameter.
(ipa_analyze_indirect_call_uses): Likewise.

gcc/testsuite/ChangeLog:

2024-02-20  Martin Jambor  

PR ipa/108802
* g++.dg/ipa/pr108802.C: New test.
---
 gcc/ipa-prop.cc | 56 +
 gcc/testsuite/g++.dg/ipa/pr108802.C | 14 
 2 files changed, 55 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr108802.C

diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index bec0ebd210c..25d252fd57c 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -2514,14 +2514,26 @@ ipa_get_stmt_member_ptr_load_param (gimple *stmt, bool 
use_delta,
   if (TREE_CODE (rhs) != MEM_REF)
 return NULL_TREE;
   rec = TREE_OPERAND (rhs, 0);
-  if (TREE_CODE (rec) != ADDR_EXPR)
-return NULL_TREE;
-  rec = TREE_OPERAND (rec, 0);
-  if (TREE_CODE (rec) != PARM_DECL
-  || !type_like_member_ptr_p (TREE_TYPE (rec), _field, _field))
+  if (TREE_CODE (rec) == ADDR_EXPR)
+{
+  rec = TREE_OPERAND (rec, 0);
+  if (TREE_CODE (rec) != PARM_DECL
+ || !type_like_member_ptr_p (TREE_TYPE (rec), _field,
+ _field))
+   return NULL_TREE;
+}
+  else if (TREE_CODE (rec) == SSA_NAME
+  && SSA_NAME_IS_DEFAULT_DEF (rec))
+{
+  if (TREE_CODE (SSA_NAME_VAR (rec)) != PARM_DECL
+ || !type_like_member_ptr_p (TREE_TYPE (TREE_TYPE (rec)), _field,
+ _field))
+   return NULL_TREE;
+}
+  else
 return NULL_TREE;
-  ref_offset = TREE_OPERAND (rhs, 1);
 
+  ref_offset = TREE_OPERAND (rhs, 1);
   if (use_delta)
 fld = delta_field;
   else
@@ -2757,17 +2769,31 @@ ipa_analyze_indirect_call_uses (struct 
ipa_func_body_info *fbi, gcall *call,
   if (rec != rec2)
 return;
 
-  index = ipa_get_param_decl_index (info, rec);
-  if (index >= 0
-  && parm_preserved_before_stmt_p (fbi, index, call, rec))
+  if (TREE_CODE (rec) == SSA_NAME)
 {
-  struct cgraph_edge *cs = ipa_note_param_call (fbi->node, index,
-   call, false);
-  cs->indirect_info->offset = offset;
-  cs->indirect_info->agg_contents = 1;
-  cs->indirect_info->member_ptr = 1;
-  cs->indirect_info->guaranteed_unmodified = 1;
+  index = ipa_get_param_decl_index (info, SSA_NAME_VAR (rec));
+  if (index < 0
+ || !parm_ref_data_preserved_p (fbi, index, call,
+gimple_assign_rhs1 (def)))
+   return;
+  by_ref = true;
 }
+  else
+{
+  index = ipa_get_param_decl_index (info, rec);
+  if (index < 0
+ || !parm_preserved_before_stmt_p (fbi, index, call, rec))
+   return;
+  by_ref = false;
+}
+
+  struct cgraph_edge *cs = ipa_note_param_call (fbi->node, index,
+   call, false);
+  cs->indirect_info->offset = offset;
+  cs->indirect_info->agg_contents = 1;
+  cs->indirect_info->member_ptr = 1;
+  cs->indirect_info->by_ref = by_ref;
+  cs->indirect_info->guaranteed_unmodified = 1;
 
   return;
 }
diff --git a/gcc/testsuite/g++.dg/ipa/pr108802.C 
b/gcc/testsuite/g++.dg/ipa/pr108802.C
new file mode 100644
index 000..2e2b6c66b64
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr108802.C
@@ -0,0 +1,14 @@
+/* { dg-do compile  } */
+/* { dg-options "-O2 -std=c++14 -fdump-ipa-inline -fno-early-inlining"  } */
+/* { dg-add-options bind_pic_locally } */
+
+struct A {
+int interesting(int x) { return 2 * x; }
+};
+
+int f1() {
+A a;
+return [&](auto&& f) { return (a.*f)(42); } (::interesting);
+}
+
+/* { dg-final { scan-ipa-dump "A::interesting\[^\\n\]*inline copy in int f1"  
"inline"  } } */
-- 
2.43.0

[PATCH] ipa: Convert lattices from pure array to vector (PR 113476)

[Martin Jambor]

On Tue, Feb 13 2024, Martin Jambor wrote:
> On Mon, Feb 12 2024, Jan Hubicka wrote:
>>> Believe it or not, even though I have re-worked the internals of the
>>> lattices completely, the array itself is older than my involvement with
>>> GCC (or at least with ipa-cp.c ;-).
>>> 
>>> So it being an array and not a vector is historical coincidence, as far
>>> as I am concerned :-).  But that may be the reason, or because vector
>>> macros at that time looked scary, or perhaps the initialization by
>>> XCNEWVEC zeroing everything out was considered attractive (I kind of
>>> like that but constructors would probably be cleaner), I don't know.
>>
>> If your class is no longer a POD, then the clearing before construcion
>> is dead and GCC may optimize it out.  So fixing this may solve some
>> surprised in foreseable future when we will try to compile older GCC's
>> with newer ones.
>>
>
> That's a good point.  I'll prepare a patch converting the whole thing to
> use constructors and vectors.
>

In PR 113476 we have discovered that ipcp_param_lattices is no longer
a POD and should be destructed.  In a follow-up discussion it
transpired that their initialization done by memsetting their backing
memory to zero is also invalid because now any write there before
construction can be considered dead.  Plus that having them in an
array is a little bit old-school and does not get the extra checking
offered by vector along with automatic construction and destruction
when necessary.

So this patch converts the array to a vector.  That however means that
ipcp_param_lattices cannot be just a forward declared type but must be
known to all code that deal with ipa_node_params and thus to all code
that includes ipa-prop.h.  Therefore I have moved ipcp_param_lattices
and the type it depends on to a new header ipa-cp.h which now
ipa-prop.h depends on.  Because we have the (IMHO not a very wise)
rule that headers don't include what they need themselves, I had to
add inclusions of ipa-cp.h and sreal.h (on which it depends) to very
many files, which made the patch rather ugly.

Bootstrapped and tested on x86_64-linux.  I also had it checked by our
script which builds more than a hundred of cross-compilers, so other
targets are hopefully also fine.

OK for master?

Martin


gcc/lto/ChangeLog:

2024-02-16  Martin Jambor  

* lto-common.cc: Include sreal.h and ipa-cp.h.
* lto-partition.cc: Include ipa-cp.h, move inclusion of sreal higher.
* lto.cc: Include sreal.h and ipa-cp.h.

gcc/ChangeLog:

2024-02-16  Martin Jambor  

* ipa-prop.h (ipa_node_params): Convert lattices to a vector, adjust
initializers in the contructor.
(ipa_node_params::~ipa_node_params): Release lattices as a vector.
* ipa-cp.h: New file.
* ipa-cp.cc: Include sreal.h and ipa-cp.h.
(ipcp_value_source): Move to ipa-cp.h.
(ipcp_value_base): Likewise.
(ipcp_value): Likewise.
(ipcp_lattice): Likewise.
(ipcp_agg_lattice): Likewise.
(ipcp_bits_lattice): Likewise.
(ipcp_vr_lattice): Likewise.
(ipcp_param_lattices): Likewise.
(ipa_get_parm_lattices): Remove assert latticess is non-NULL).
(ipa_value_from_jfunc): Adjust a check for empty lattices.
(ipa_context_from_jfunc): Likewise.
(ipa_agg_value_from_jfunc): Likewise.
(merge_agg_lats_step): Do not memset new aggregate lattices to zero.
(ipcp_propagate_stage): Allocate lattices in a vector as opposed to
just in contiguous memory.
(ipcp_store_vr_results): Adjust a check for empty lattices.
* auto-profile.cc: Include sreal.h and ipa-cp.h.
* cgraph.cc: Likewise.
* cgraphclones.cc: Likewise.
* cgraphunit.cc: Likewise.
* config/aarch64/aarch64.cc: Likewise.
* config/i386/i386-builtins.cc: Likewise.
* config/i386/i386-expand.cc: Likewise.
* config/i386/i386-features.cc: Likewise.
* config/i386/i386-options.cc: Likewise.
* config/i386/i386.cc: Likewise.
* config/rs6000/rs6000.cc: Likewise.
* config/s390/s390.cc: Likewise.
* gengtype.cc (open_base_files): Added sreal.h and ipa-cp.h to the
files to be included in gtype-desc.cc.
* gimple-range-fold.cc: Include sreal.h and ipa-cp.h.
* ipa-devirt.cc: Likewise.
* ipa-fnsummary.cc: Likewise.
* ipa-icf.cc: Likewise.
* ipa-inline-analysis.cc: Likewise.
* ipa-inline-transform.cc: Likewise.
* ipa-inline.cc: Include ipa-cp.h, move inclusion of sreal.h higher.
* ipa-modref.cc: Include sreal.h and ipa-cp.h.
* ipa-param-manipulation.cc: Likewise.
* ipa-predicate.cc: Likewise.
* ipa-profile.cc: Likewise.
* ipa-prop.cc: Likewise.
(ipa_node_params_t::duplicate):

[PATCH] testsuite: Fix guality/ipa-sra-1.c to work with return IPA-VRP

[Martin Jambor]

Hi,

the test guality/ipa-sra-1.c stopped working after
r14-5628-g53ba8d669550d3 because the variable from which the values of
removed parameters could be calculated is also removed with it.  Fixed
with this patch which stops a function from returning a constant.

I have also noticed that the XFAILed test passes at -O0 -O1 and -Og on
all (three) targets I have tried, not just aarch64, so I extended the
xfail exception accordingly.

Tested by running make -k check-gcc
RUNTESTFLAGS="guality.exp=ipa-sra-1.c" on x86_64-linux, aarch64-linux
and ppc64le-linux.  I hope it is obvious change for me to commit
without approval which I will do later today.

Thanks,

Martin


gcc/testsuite/ChangeLog:

2024-02-14  Martin Jambor  

* gcc.dg/guality/ipa-sra-1.c (get_val1): Move up in the file.
(get_val2): Likewise.
(bar): Do not return a constant.  Extend xfail exception for all
targets.
---
 gcc/testsuite/gcc.dg/guality/ipa-sra-1.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c 
b/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c
index 9ef4eac93a7..55267c6f838 100644
--- a/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c
+++ b/gcc/testsuite/gcc.dg/guality/ipa-sra-1.c
@@ -1,6 +1,10 @@
 /* { dg-do run } */
 /* { dg-options "-g -fno-ipa-icf" } */
 
+int __attribute__((noipa))
+get_val1 (void)  {return 20;}
+int __attribute__((noipa))
+get_val2 (void)  {return 7;}
 
 void __attribute__((noipa))
 use (int x)
@@ -12,8 +16,8 @@ static int __attribute__((noinline))
 bar (int i, int k)
 {
   asm ("" : "+r" (i));
-  use (i); /* { dg-final { gdb-test . "k" "3" { xfail { ! { 
aarch64*-*-* && { any-opts "-O0" "-O1" "-Og" } } } } } } */
-  return 6;
+  use (i); /* { dg-final { gdb-test . "k" "3" { xfail { ! { 
*-*-*-* && { any-opts "-O0" "-O1" "-Og" } } } } } } */
+  return 6 + get_val1();
 }
 
 volatile int v;
@@ -30,11 +34,6 @@ foo (int i, int k)
 
 volatile int v;
 
-int __attribute__((noipa))
-get_val1 (void)  {return 20;}
-int __attribute__((noipa))
-get_val2 (void)  {return 7;}
-
 int
 main (void)
 {
-- 
2.43.0

Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)

[Martin Jambor]

Hi,

On Mon, Feb 12 2024, Jan Hubicka wrote:
>> Hi,
>> 
>> In PR 113476 we have discovered that ipcp_param_lattices is no longer
>> a POD and should be destructed.  This patch does that, calling
>> destructor on each element of the array containing them when the
>> corresponding summary of a node is freed.  An alternative would be to
>> change the XCNEWVEC-and-placement-new to initializations in
>> constructors of all things in ipcp_param_lattices and then simply use
>> normal operators new and delete.  I am not sure, the initialization
>> through XCNEWVEC may be a bit more efficient although that is probably
>> not a big concern.  In the end, I opted for a simpler solution for
>> stage 4.
>> 
>> I have verified that valgrind no longer reports lost memory blocks
>> allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source
>> (dwarf2out.i) attached to Bugzilla.  The patch also passes bootstrap and
>> LTO bootstrap and testing on x86_64-linux.
>> 
>> OK for master?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2024-02-09  Martin Jambor  
>> 
>>  PR tree-optimization/113476
>>  * ipa-prop.h (ipa_node_params::~ipa_node_params): Moved...
>>  * ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here.  Added
>>  destruction of lattices.
>
> OK.
> So you do not use vectors (which would also handle the destruction)
> basically to save space needed to keep the
> size of the vector since that is known from the parameter count?
>

OK, so when I started looking at converting lattices to vector, it
immediately became clear why it is an array.  The type of the element of
the array (ipcp_param_lattices and all it contains) is only forward
declared in ipa-prop.h where ipa_node_params is defined which can
therefore just contain a pointer.  The actual definition of
ipcp_param_lattices is then done only in ipa-cp.c.

Converting the array to a vector would means moving ipcp_param_lattices
together with ipcp_lattice, ipcp_value, ipcp_value_base,
ipcp_agg_lattice, ipcp_bits_lattice, ipcp_vr_lattice from ipa-cp.c to
ipa-prop.h.  Or an ipa-cp.h which ipa-prop.h would require/include.  But
perhaps that is the proper C++ thing to do :-/

Martin

Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)

[Martin Jambor]

On Mon, Feb 12 2024, Jan Hubicka wrote:
>> Believe it or not, even though I have re-worked the internals of the
>> lattices completely, the array itself is older than my involvement with
>> GCC (or at least with ipa-cp.c ;-).
>> 
>> So it being an array and not a vector is historical coincidence, as far
>> as I am concerned :-).  But that may be the reason, or because vector
>> macros at that time looked scary, or perhaps the initialization by
>> XCNEWVEC zeroing everything out was considered attractive (I kind of
>> like that but constructors would probably be cleaner), I don't know.
>
> If your class is no longer a POD, then the clearing before construcion
> is dead and GCC may optimize it out.  So fixing this may solve some
> surprised in foreseable future when we will try to compile older GCC's
> with newer ones.
>

That's a good point.  I'll prepare a patch converting the whole thing to
use constructors and vectors.

Thanks,

Martin

Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)

[Martin Jambor]

On Mon, Feb 12 2024, Jan Hubicka wrote:
>> Hi,
>> 
>> In PR 113476 we have discovered that ipcp_param_lattices is no longer
>> a POD and should be destructed.  This patch does that, calling
>> destructor on each element of the array containing them when the
>> corresponding summary of a node is freed.  An alternative would be to
>> change the XCNEWVEC-and-placement-new to initializations in
>> constructors of all things in ipcp_param_lattices and then simply use
>> normal operators new and delete.  I am not sure, the initialization
>> through XCNEWVEC may be a bit more efficient although that is probably
>> not a big concern.  In the end, I opted for a simpler solution for
>> stage 4.
>> 
>> I have verified that valgrind no longer reports lost memory blocks
>> allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source
>> (dwarf2out.i) attached to Bugzilla.  The patch also passes bootstrap and
>> LTO bootstrap and testing on x86_64-linux.
>> 
>> OK for master?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2024-02-09  Martin Jambor  
>> 
>>  PR tree-optimization/113476
>>  * ipa-prop.h (ipa_node_params::~ipa_node_params): Moved...
>>  * ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here.  Added
>>  destruction of lattices.
>
> OK.
> So you do not use vectors (which would also handle the destruction)
> basically to save space needed to keep the
> size of the vector since that is known from the parameter count?
>

Believe it or not, even though I have re-worked the internals of the
lattices completely, the array itself is older than my involvement with
GCC (or at least with ipa-cp.c ;-).

So it being an array and not a vector is historical coincidence, as far
as I am concerned :-).  But that may be the reason, or because vector
macros at that time looked scary, or perhaps the initialization by
XCNEWVEC zeroing everything out was considered attractive (I kind of
like that but constructors would probably be cleaner), I don't know.

Martin

[PATCH] ipa: call destructors on lattices before freeing them (PR 113476)

[Martin Jambor]

Hi,

In PR 113476 we have discovered that ipcp_param_lattices is no longer
a POD and should be destructed.  This patch does that, calling
destructor on each element of the array containing them when the
corresponding summary of a node is freed.  An alternative would be to
change the XCNEWVEC-and-placement-new to initializations in
constructors of all things in ipcp_param_lattices and then simply use
normal operators new and delete.  I am not sure, the initialization
through XCNEWVEC may be a bit more efficient although that is probably
not a big concern.  In the end, I opted for a simpler solution for
stage 4.

I have verified that valgrind no longer reports lost memory blocks
allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source
(dwarf2out.i) attached to Bugzilla.  The patch also passes bootstrap and
LTO bootstrap and testing on x86_64-linux.

OK for master?

Thanks,

Martin


gcc/ChangeLog:

2024-02-09  Martin Jambor  

PR tree-optimization/113476
* ipa-prop.h (ipa_node_params::~ipa_node_params): Moved...
* ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here.  Added
destruction of lattices.
---
 gcc/ipa-cp.cc  | 17 +
 gcc/ipa-prop.h |  9 -
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index e85477df32d..9864ff052de 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -399,6 +399,23 @@ public:
   bool virt_call;
 };
 
+/* Destructor of node function summary, placed here because it mainly must
+   destruct value range lattices not known outside of this source file.  */
+
+ipa_node_params::~ipa_node_params ()
+{
+  if (lattices)
+{
+  int count = ipa_get_param_count (this);
+  for (int i = 0; i < count; i++)
+   lattices[i].~ipcp_param_lattices ();
+  free (lattices);
+}
+  vec_free (descriptors);
+  known_csts.release ();
+  known_contexts.release ();
+}
+
 /* Allocation pools for values and their sources in ipa-cp.  */
 
 object_allocator > ipcp_cst_values_pool
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index 9c78dc9f486..fe401640824 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -670,15 +670,6 @@ ipa_node_params::ipa_node_params ()
 {
 }
 
-inline
-ipa_node_params::~ipa_node_params ()
-{
-  free (lattices);
-  vec_free (descriptors);
-  known_csts.release ();
-  known_contexts.release ();
-}
-
 /* Intermediate information that we get from alias analysis about a particular
parameter in a particular basic_block.  When a parameter or the memory it
references is marked modified, we use that information in all dominated
-- 
2.43.0

Re: [RFC] GCC Security policy

[Martin Jambor]

Hi,

On Fri, Feb 09 2024, Siddhesh Poyarekar wrote:
> On 2024-02-09 10:38, Martin Jambor wrote:
>> If anyone is interested in scoping this and then mentoring this as a
>> Google Summer of Code project this year then now is the right time to
>> speak up!
>
> I can help with mentoring and reviews, although I'll need someone to 
> assist with actual approvals.

I'm sure that we could manage that.  The project does not look like it
would be a huge one.

>
> There are two distinct sets of ideas to explore, one is privilege 
> management and the other sandboxing.
>
> For privilege management we could add a --allow-root driver flag that 
> allows gcc to run as root.  Without the flag one could either outright 
> refuse to run or drop privileges and run.  Dropping privileges will be a 
> bit tricky to implement because it would need a user to drop privileges 
> to and then there would be the question of how to manage file access to 
> read the compiler input and write out the compiler output.  If there's 
> no such user, gcc could refuse to run as root by default.  I wonder 
> though if from a security posture perspective it makes sense to simply 
> discourage running as root all the time and not bother trying to make it 
> work with dropped privileges and all that.  Of course it would mean that 
> this would be less of a "project"; it'll be a simple enough patch to 
> refuse to run until --allow-root is specified.

Yeah, this would not be enough for a GSoC project, not even for their
new small project category.

Additionally, I think that many, if not all, Linux distributions that
build binary packages do it in a VM/container/chroot where they do it
simply under root because the whole environment is there just for the
build.  So this would complicate lives for an important set of our
users.

>
> This probably ties in somewhat with an idea David Malcolm had riffed on 
> with me earlier, of caching files for diagnostics.  If we could unify 
> file accesses somehow, we could make this happen, i.e. open/read files 
> as root and then do all execution as non-root.
>
> Sandboxing will have similar requirements, i.e. map in input files and 
> an output file handle upfront and then unshare() into a sandbox to do 
> the actual compilation.  This will make sure that at least the 
> processing of inputs does not affect the system on which the compilation 
> is being run.

Right.  As we often just download some (sometimes large) pre-processed
source from Bugzilla and then happily run GCC on it on our computers,
this feature might be actually useful for us (still, we'd probably need
a more concrete description of what we want, would e.g. using "-wrapper
gdb,--args" work in such a sandbox?).  I agree that for some even
semi-complex builds, a more general sandboxing solution is probably
better.

Martin

Re: [RFC] GCC Security policy

[Martin Jambor]

Hi,

On Tue, Aug 08 2023, Richard Biener via Gcc-patches wrote:
> On Tue, Aug 8, 2023 at 2:33 PM Siddhesh Poyarekar  wrote:
>>
>> On 2023-08-08 04:16, Richard Biener wrote:
>> > On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches
>> >  wrote:
>> >>
>> >> FOSS Best Practices recommends that projects have an official Security
>> >> policy stated in a SECURITY.md or SECURITY.txt file at the root of the
>> >> repository.  GLIBC and Binutils have added such documents.
>> >>
>> >> Appended is a prototype for a Security policy file for GCC based on the
>> >> Binutils document because GCC seems to have more affinity with Binutils as
>> >> a tool. Do the runtime libraries distributed with GCC, especially libgcc,
>> >> require additional security policies?
>> >>
>> >> [ ] Is it appropriate to use the Binutils SECURITY.txt as the starting
>> >> point or should GCC use GLIBC SECURITY.md as the starting point for the 
>> >> GCC
>> >> Security policy?
>> >>
>> >> [ ] Does GCC, or some components of GCC, require additional care because 
>> >> of
>> >> runtime libraries like libgcc and libstdc++, and because of gcov and
>> >> profile-directed feedback?
>> >
>> > I do think that the runtime libraries should at least be explicitly 
>> > mentioned
>> > because they fall into the "generated output" category and bugs in the
>> > runtime are usually more severe as affecting a wider class of inputs.
>>
>> Ack, I'd expect libstdc++ and libgcc to be aligned with glibc's
>> policies.  libiberty and others on the other hand, would probably be
>> more suitably aligned with binutils libbfd, where we assume trusted input.
>>
>> >> Thoughts?
>> >>
>> >> Thanks, David
>> >>
>> >> GCC Security Process
>> >> 
>> >>
>> >> What is a GCC security bug?
>> >> ===
>> >>
>> >>  A security bug is one that threatens the security of a system or
>> >>  network, or might compromise the security of data stored on it.
>> >>  In the context of GCC there are two ways in which such
>> >>  bugs might occur.  In the first, the programs themselves might be
>> >>  tricked into a direct compromise of security.  In the second, the
>> >>  tools might introduce a vulnerability in the generated output that
>> >>  was not already present in the files used as input.
>> >>
>> >>  Other than that, all other bugs will be treated as non-security
>> >>  issues.  This does not mean that they will be ignored, just that
>> >>  they will not be given the priority that is given to security bugs.
>> >>
>> >>  This stance applies to the creation tools in the GCC (e.g.,
>> >>  gcc, g++, gfortran, gccgo, gccrs, gnat, cpp, gcov, etc.) and the
>> >>  libraries that they use.
>> >>
>> >> Notes:
>> >> ==
>> >>
>> >>  None of the programs in GCC need elevated privileges to operate and
>> >>  it is recommended that users do not use them from accounts where such
>> >>  privileges are automatically available.
>> >
>> > I'll note that we could ourselves mitigate some of that by handling 
>> > privileged
>> > invocation of the driver specially, dropping privs on exec of the sibling 
>> > tools
>> > and possibly using temporary files or pipes to do the parts of the I/O that
>> > need to be privileged.
>>
>> It's not a bad idea, but it ends up giving legitimizing running the
>> compiler as root, pushing the responsibility of privilege management to
>> the driver.  How about rejecting invocation as root altogether by
>> default, bypassed with a --run-as-root flag instead?
>>
>> I've also been thinking about a --sandbox flag that isolates the build
>> process (for gcc as well as binutils) into a separate namespace so that
>> it's usable in a restricted mode on untrusted sources without exposing
>> the rest of the system to it.
>
> There's probably external tools to do this, not sure if we should replicate
> things in the driver for this.
>
> But sure, I think the driver is the proper point to address any of such
> issues - iff we want to address them at all.  Maybe a nice little
> google summer-of-code project ;)
>

If anyone is interested in scoping this and then mentoring this as a
Google Summer of Code project this year then now is the right time to
speak up!

Thanks,

Martin

[PATCH] ipa: Avoid excessive removing of SSAs (PR 113757)

[Martin Jambor]

Hi,

PR 113757 shows that the code which was meant to debug-reset and
remove SSAs defined by LHSs of calls redirected to
__builtin_unreachable can trigger also when speculative
devirtualization creates a call to a noreturn function (and since it
is noreturn, it does not bother dealing with its return value).

What is more, it seems that the code handling this case is not really
necessary.  I feel slightly idiotic about this because I have a
feeling that I added it because of a failing test-case but I can
neither find the testcase nor a reason why the code in
cgraph_edge::redirect_call_stmt_to_callee would not be sufficient (it
turns the SSA name into a default-def, a bit like IPA-SRA, but any
code dominated by a call to a noreturn is not dangerous when it comes
to its side-effects).  So this patch just removes the handling.

Bootstrapped and tested on x86_64-linux and ppc64le-linux.  I have also
LTO-bootstrapped and LTO-profilebootstrapped the patch on x86_64-linux.

OK for master?

Thanks,

Martin


gcc/ChangeLog:

2024-02-07  Martin Jambor  

PR ipa/113757
* tree-inline.cc (redirect_all_calls): Remove code adding SSAs to
id->killed_new_ssa_names.

gcc/testsuite/ChangeLog:

2024-02-07  Martin Jambor  

PR ipa/113757
* g++.dg/ipa/pr113757.C: New test.
---
 gcc/testsuite/g++.dg/ipa/pr113757.C | 14 ++
 gcc/tree-inline.cc  | 14 ++
 2 files changed, 16 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr113757.C

diff --git a/gcc/testsuite/g++.dg/ipa/pr113757.C 
b/gcc/testsuite/g++.dg/ipa/pr113757.C
new file mode 100644
index 000..885d4010a10
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr113757.C
@@ -0,0 +1,14 @@
+// { dg-do compile }
+// { dg-options "-O2 -fPIC" }
+// { dg-require-effective-target fpic }
+
+long size();
+struct ll {  virtual int hh();  };
+ll  *slice_owner;
+int ll::hh() { __builtin_exit(0); }
+int nn() {
+  if (size())
+return 0;
+  return slice_owner->hh();
+}
+int (*a)() = nn;
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index 75c10eb7dfc..cac41b4f031 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2984,23 +2984,13 @@ redirect_all_calls (copy_body_data * id, basic_block bb)
   gimple *stmt = gsi_stmt (si);
   if (is_gimple_call (stmt))
{
- tree old_lhs = gimple_call_lhs (stmt);
  struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
  if (edge)
{
  if (!id->killed_new_ssa_names)
id->killed_new_ssa_names = new hash_set (16);
- gimple *new_stmt
-   = cgraph_edge::redirect_call_stmt_to_callee (edge,
-   id->killed_new_ssa_names);
- if (old_lhs
- && TREE_CODE (old_lhs) == SSA_NAME
- && !gimple_call_lhs (new_stmt))
-   /* In case of IPA-SRA removing the LHS, the name should have
-  been already added to the hash.  But in case of redirecting
-  to builtin_unreachable it was not and the name still should
-  be pruned from debug statements.  */
-   id->killed_new_ssa_names->add (old_lhs);
+ cgraph_edge::redirect_call_stmt_to_callee (edge,
+   id->killed_new_ssa_names);
 
  if (stmt == last && id->call_stmt && maybe_clean_eh_stmt (stmt))
gimple_purge_dead_eh_edges (bb);
-- 
2.43.0

Re: GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

this is just a reminder that the organization application period of GSoC
2024 closes on Tuesday February 6th (6pm UTC).  We have already applied
but that is when we are expected to have our project idea list basically
ready.  So please review old ideas and if you have a new one and/or
would like to be a mentor, please speak up.

Thanks,

Martin


On Mon, Jan 15 2024, Martin Jambor wrote:
[...]
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

Re: GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

this is just a reminder that the organization application period of GSoC
2024 closes on Tuesday February 6th (6pm UTC).  We have already applied
but that is when we are expected to have our project idea list basically
ready.  So please review old ideas and if you have a new one and/or
would like to be a mentor, please speak up.

Thanks,

Martin


On Mon, Jan 15 2024, Martin Jambor wrote:
[...]
>  The most important bit: 
>
> I would like to ask all (moderately) seasoned GCC contributors to
> consider mentoring a contributor this year and ideally also come up with
> a project that they would like to lead.  I'm collecting proposal on our
> wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
> to the top list there.  Or, if you are unsure, post your offer and
> project idea as a reply here to the mailing list.
>
> Additionally, if you have added an idea to the list in the recent years,
> please review it whether it is still up-to-date or needs adjusting or
> should be removed altogether.
>
> =
>
> At this point, we need to collect list of project ideas.  Eventually,
> each listed project idea should have:
>
>   a) a project title,
>   b) more detailed description of the project (2-5 sentences),
>   c) expected outcomes (we do have a catch-almost-all formulation that
>  outcome is generally patches at the bottom of the list on the
>  wiki),
>   d) skills required/preferred,
>   e) project size - whether it is expected to take approximately 350,
>  175 or just 90 hours (the last option in new in 2024, see below),
>   f) difficulty (easy, hard or medium, but we don't really have easy
>  projects), and
>   g) expected mentors.
>
> Project ideas that come without an offer to also mentor them are always
> fun to discuss, by all means feel free to reply to this email with yours
> and I will attempt to find a mentor, but please be aware that we can
> only use the suggestion it if we actually find one or ideally two.
>
> Everybody in the GCC community is invited to go over
> https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
> otherwise bad project suggestions and help improve viable ones.
>
> Finally, please continue helping (prospective) students figure stuff out
> about GCC like you have always done in the past.
>
> As far as I know, GSoC 2024 should be quite similar to the last year,
> the most important parameters probably are these:
>
>   - Contributors (formerly students) must either be full-time students
> or be "beginners to open source."
>
>   - There are now three project sizes: roughly 90 hors (small), roughly
> 175 hours (medium-sized) and roughly 350 hours (large) of work in
> total.  The small option is new this year but because our projects
> usually have a lengthy learning period, I think we will usually want
> to stick to the medium and large variants.
>
>   - Timing should be pretty much as flexible as last year.  The
> recommended "standard" duration is 12 weeks but depending on
> contributor's and mentor's needs and circumstances, projects can
> take anywhere between 10 and 22 weeks.  There will be one mid-term
> and one final evaluation.
>
> For further details you can see:
>
>   - The announcement of GSoC 2024:
> 
> https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html
>
>   - GSoC rules:
> https://summerofcode.withgoogle.com/rules
>
>   - The detailed GSoC 2024 timeline:
> https://developers.google.com/open-source/gsoc/timeline
>
>   - Elaborate project idea guidelines:
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> Thank you very much for your participation and help.  Let's hope we
> attract some great contributors again this year.
>
> Martin

Re: [PATCH] ipa-cp: Fix check for exceeding param_ipa_cp_value_list_size (PR 113490)

[Martin Jambor]

Hi,

On Mon, Jan 22 2024, Jan Hubicka wrote:
>> Hi,
>> 
>> When the check for exceeding param_ipa_cp_value_list_size limit was
>> modified to be ignored for generating values from self-recursive
>> calls, it should have been changed from equal to, to equals toor is
>> greater than.  This omission manifests itself as PR 113490.
>> 
>> When I examined the condition I also noticed that the parameter should
>> come from the callee rather than the caller, since the value list is
>> associated with the former and not the latter.  In practice the limit
>> is of course very likely to be the same, but I fixed this aspect of
>> the condition too.  I briefly audited all other uses of opt_for_fn in
>> ipa-cp.cc and all the others looked OK.
>> 
>> Bootstrapped and tested on x86_64-linux.  OK for master?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> gcc/ChangeLog:
>> 
>> 2024-01-19  Martin Jambor  
>> 
>>  PR ipa/113490
>>  * ipa-cp.cc (ipcp_lattice::add_value): Bail out if value
>>  count is equal or greater than the limit.  Use the limit from the
>>  callee.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2024-01-19  Martin Jambor  
>> 
>>  PR ipa/113490
>>  * gcc.dg/ipa/pr113490.c: New test.
> OK,
> thanks!

thank you, I have pushed the following, which has a tweak in the added
test so that it is only run on targets which support the required vectors.

Martin




When the check for exceeding param_ipa_cp_value_list_size limit was
modified to be ignored for generating values from self-recursive
calls, it should have been changed from equal to, to equals to or is
greater than.  This omission manifests itself as PR 113490.

When I examined the condition I also noticed that the parameter should
come from the callee rather than the caller, since the value list is
associated with the former and not the latter.  In practice the limit
is of course very likely to be the same, but I fixed this aspect of
the condition too.  I briefly audited all other uses of opt_for_fn in
ipa-cp.cc and all the others looked OK.

gcc/ChangeLog:

2024-01-19  Martin Jambor  

    PR ipa/113490
* ipa-cp.cc (ipcp_lattice::add_value): Bail out if value
count is equal or greater than the limit.  Use the limit from the
callee.

gcc/testsuite/ChangeLog:

2024-01-22  Martin Jambor  

PR ipa/113490
* gcc.dg/ipa/pr113490.c: New test.
---
 gcc/ipa-cp.cc   |  2 +-
 gcc/testsuite/gcc.dg/ipa/pr113490.c | 31 +
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr113490.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index b1e2a3a829a..e85477df32d 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -2298,7 +2298,7 @@ ipcp_lattice::add_value (valtype newval, 
cgraph_edge *cs,
return false;
   }
 
-  if (!same_lat_gen_level && values_count == opt_for_fn (cs->caller->decl,
+  if (!same_lat_gen_level && values_count >= opt_for_fn (cs->callee->decl,
param_ipa_cp_value_list_size))
 {
   /* We can only free sources, not the values themselves, because sources
diff --git a/gcc/testsuite/gcc.dg/ipa/pr113490.c 
b/gcc/testsuite/gcc.dg/ipa/pr113490.c
new file mode 100644
index 000..526e22b3787
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr113490.c
@@ -0,0 +1,31 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O3 -Wno-psabi"  } */
+
+typedef char A __attribute__((vector_size (64)));
+typedef short B __attribute__((vector_size (64)));
+typedef unsigned C __attribute__((vector_size (64)));
+typedef long D __attribute__((vector_size (64)));
+typedef __int128 E __attribute__((vector_size (64)));
+
+D bar1_D_0;
+E bar4 (A, D);
+
+E
+bar1 (C C_0)
+{
+  C_0 >>= 1;
+  bar4 ((A) C_0, bar1_D_0);
+  bar4 ((A) (E) {~0 }, (D) (A){ ~0 });
+  bar4 ((A) (B) { ~0 }, (D) (C) { ~0 });
+  bar1 ((C) (D){ 0, ~0});
+  bar4 ((A) C_0, bar1_D_0);
+  (A) { bar1 ((C) { 7})[5] - C_0[63], bar4 ((A) (D) {~0}, (D) (C) { 0, 
~0})[3]};
+}
+
+E
+bar4 (A A_0, D D_0)
+{
+  bar1 ((C) A_0);
+  bar1 ((C) {5});
+  bar1 ((C) D_0);
+}
-- 
2.43.0

Re: GSoC 2024 Application: Rupali Paliwal

[Martin Jambor]

Hello,

We are delighted you found contributing to GCC interesting.  GCC has
applied to be part of GSoC 2024 but of course selected organizations
have not been announced yet this year. More comments inline.

On Mon, Jan 22 2024, Rupali P via Gcc wrote:
> Respected GSoC Review Team,
>
>
> I am writing to express my enthusiastic interest in participating in Google
> Summer of Code 2024 with Tobias Burnus. Below, I've outlined my project
> idea, shared insights into my background and passion for open source, and
> demonstrated my commitment to contributing to Tobias Burnus.
>
>
> *Project Proposal:*
>
> *Title*:
>
> *Fortran – improved argument compile-time checking* – The compiler does
> check for the arguments in the *same* file – but it could do better in some
> cases, i.e. checking better the interface data or updating the expected
> input better from the user. This project would be mentored by Tobias
> Burnus. Required skills include C/C++; some knowledge of Fortran helps, but
> is not needed.
>
>
> *1. Idea Description:*
>
> *Project Title: *Fortran – Improved Argument Compile-Time Checking.
>
> *Idea Description:.*
>
> The goal of this project is to enhance the compile-time checking
> capabilities of the Fortran compiler, specifically focusing on improving
> the analysis of arguments within the same file. While the current compiler
> performs basic argument checks, there is room for improvement, particularly
> in checking interface data and updating expected input information derived
> from the usage context.
>
>
> *Key Components:.*
>
> 1. .Interface Data Analysis:.
>
> - Implement an advanced analysis mechanism to better check interface data
> related to function and subroutine arguments.

I am afraid this needs more detail, especially at least roughly how you
plan to achieve that.  Please read through
https://gcc.gnu.org/wiki/SummerOfCode#Application

>
> - Explore ways to detect and address discrepancies in argument
> specifications within the Fortran code.

I'm afraid I don't understand what you mean.  Anything beyond giving an
error or warning?

>
> 2. .Optimizing Expected Input:.
>
> - Develop strategies to improve the compiler's ability to update expected
> input information based on the usage of arguments in the code.

What do you mean by "update input"?

>
> - Enhance the accuracy of expected input to provide more meaningful
> feedback to developers during the compilation process.
>

This is a way too general statement as well.

>
> Mentor:
>
> Tobias Burnus will serve as the mentor for this project, offering guidance
> and expertise in compiler development.
>
>
> *2. Enthusiasm and Devotion:*
>
> Thrilled about the Fortran – Improved Argument Compile-Time Checking
> project in GSoC 2024 under Tobias Burnus' mentorship. My passion for
> compiler development, Linux OS internals, and open-source fuels my
> eagerness to enhance Fortran's compile-time checking, ensuring code
> reliability and contributing meaningfully to the community.

Enthusiasm is a wonderful thing but you also need to demonstrate
competence.  Please look again at the "Before you apply" section of the
idea page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and
make sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Try to identify places in the compiler which would need changing to
achieve the project goal.  Feel free to ask specific technical questions
on this list and IRC as you do so.

[...]

>
>
> *4. .Targeted Application:.*
>
> - Emphasize the importance of tailoring each application to the specific
> mentoring organization and project.

???

>
> - Mention unique aspects of the project and organization that align with
> your skills and interests.
>

???

But you don't really need to do either if you can convince us you have
not just the determination but also the skills to successfully finish
the project.  So look at our code, try it out an tell us what you'd
change there to accomplish the project goals.

Good luck,

Martin

Re: GSoC: Application for Rust Front-End Project at GCC

[Martin Jambor]

Hello Arpit,

We are very happy that you found contributing to GCC-rust interesting.
GCC has applied to be part of GSoC 2024 but of course selected
organizations have not been announced yet this year.


On Sat, Dec 30 2023, CS21B062 ARPIT GUPTA wrote:
> Dear GCC Community,
>
> I hope this email finds you well. My name is Arpit and I am writing to
> express my interest in participating in GSoC, specifically for the
> Rust Front-End project at GCC. Having completed an internship in
> Compiler Design at IIT Hyderabad in my IInd Year , where I gained
> hands-on experience in code compliance, optimization analysis, and
> cross-compilation, I am eager to contribute to the development of the
> Rust compiler front-end.

Please note that Rust-GCC projects are a bit special in the sense that
they are often discussed primarily on Zulip of the gcc-rust team:

https://gcc-rust.zulipchat.com/

So I suggest you also reach out to them there as well.  You can refer to
your email in the archives
(https://gcc.gnu.org/pipermail/gcc/2023-December/243089.html) so that
you don't have to repeat everything.

Good luck!

Martin



>
> After carefully reviewing the available projects, I am particularly
> interested in the following project:
>
> Project Choice:
> Rust Front-End,  all the subdomains
>
> Project Description:
> Rust supports several metadata outputs crucial for importing crates.
> The goal of this project is to extend the support for metadata exports
> in the Rust Front-End being developed by GCC. I am confident in my
> understanding of compilation and linking processes, which will be
> essential for this project. I am excited about the opportunity to work
> on this challenging task and contribute to the completion of metadata
> exports.
>
> Why This Project:
> I believe that improving metadata exports is a crucial step towards
> enhancing the interoperability of the Rust compiler with other tools
> and platforms. This effort aligns with my passion for compiler design
> and would significantly contribute to the overall functionality of the
> Rust Front-End. Moreover, as an intern I have already developed some
> compliance checkers using clang for C language in accordance with
> AUTOSAR.
>
> Proposed Timeline:
>
> Weeks 1-2: In-depth analysis of the existing metadata export framework
> in GCC and understanding the requirements for Rust.
> Weeks 3-5: Implementation of basic metadata export functionality for
> the Rust Front-End.
> Weeks 6-8: Testing and debugging of the implemented features,
> addressing any issues that may arise during the integration.
> Weeks 9-12: Fine-tuning, optimization, and documentation of the
> metadata export process, ensuring it meets the project's goals.
>
> I am committed to engaging with the community throughout the
> development process, seeking feedback, and incorporating suggestions
> to ensure the success of the project. I have subscribed to the
> gcc@gcc.gnu.org mailing list and will actively participate in
> discussions regarding the Rust Front-End project.
>
> I would appreciate any feedback or guidance on my proposed project and
> timeline. I am eager to contribute to the GCC community and make a
> meaningful impact on the Rust Front-End project.
>
> Thank you for considering my application. I look forward to the
> opportunity to contribute to the GCC community during GSoC 2023.
>
> Best regards,
> Arpit Gupta,
> Code Club Head
> ph: 8299480636

RE: Open Available Projects for Google Summer of Code 2024

[Martin Jambor]

On Mon, Jan 22 2024, Vedant Tewari wrote:
Hello Vedant,

> Hello,
> I am expressing my interest as a potential gsoc participant, based on this
> https://gcc.gnu.org/wiki/SummerOfCode, are there any available projects
> that you might recommend or might be best suited for a potential proposal
> for the upcoming gsoc. I am interested in working with optimization passes
> and was hoping for some guidance!

We are delighted you found contributing to GCC interesting.  GCC has
applied to be part of GSoC 2024 but of course selected organizations
have not been announced yet this year.

The idea page is still undergoing review to reflect changes over the
last year, nevertheless a lot of the ideas will stay the same or look
very similar.  It currently does not contain much work on any general
optimization pass, the reason is that what still remains to be done is
often difficult and not easily explained to a complete newcomer.  But we
are still looking for items to populate that list and so we still may
find some.  So keep looking there but I'd also encourage you to come and
discuss ideas on our IRC channel.

>From what we already have, I'd suggest looking into what is called
"Separate Host Process Offloading."  While it is not optimization work
itself, it would introduce you to the world of offloading and I believe
there is still a lot of unexplored optimization opportunities when it
comes to passing and using more information from the main host program
to the bits running elsewhere.  But in order to experiment and test, we
need a vehicle to do the offloading simply.

Make also sure to go through the "Before you apply" section of the idea
page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make
sure you are able to build, install and test GCC and then have it
generate dumps during compilation. Definitely feel free to ask for help
on the mailing list (which I'm CCing) with any specific GCC development
issues you may encounter.

Good luck!

Martin

Re: GSoc Topics

[Martin Jambor]

Hello,

We are delighted you found contributing to GCC interesting.  GCC has
applied to be part of GSoC 2024 but of course selected organizations
have not been announced yet.

On Fri, Jan 12 2024, Gaurang Aswal via Gcc wrote:
> Hey I am Gaurang Aswal a 4th year B.E. Computer Science student from BITS
> Goa, India and wanted some info and insights on the Fortran projects and I
> am interested in working on them.

While the list of suggested projects at
https://gcc.gnu.org/wiki/SummerOfCode is undergoing review for 2024, I
think the Fortran ones will not change much.  Please look over them, try
to figure out what they would entail and which you'd like best.  In this
reply I have also CCed the Fortran mailing list, people there might help
you decide which Fortan project would be the best for you.


> I have basic knowledge of C/C++ and I
> have completed my basic computer science courses in the same language,
> which included Object Oriented Programming, Data Structures and Algorithms,
> Computer Architecture and Operating Systems. I would like to keep in touch
> and want to know how to proceed working on the topics.

Contributing to the compiler also requires some rudimentary theoretical
background in compilers, at the very least understanding of the concept
of Intermediate Representation (IR), often also called Intermediate
Language (IL).  Googling either of the two terms should help you to find
a lot of material to familiarize yourself with it.

Please also look again at the "Before you apply" section of the idea
page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make
sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Also, feel free to ask for help here with any specific GCC development
issues you may encounter.

Good luck,

Martin

Re: GCC GSoC 2024: Call for project ideas and mentors (rust)

[Martin Jambor]

Hi Arthur,

On Fri, Jan 19 2024, Arthur Cohen wrote:
> Hi Martin,
>
> On 1/15/24 18:48, Martin Jambor wrote:
>> Hello,
>> 
>> another year has passed, Google has announced there will be again Google
>> Summer of Code (GsoC) in 2024 and the deadline for organizations to
>> apply is already approaching (February 6th).  I'd like to volunteer to
>> be the main org-admin for GCC again but let me know if you think I
>> shouldn't or that someone else should or if you want to do it instead.
>> Otherwise I'll assume that I will and I hope that I can continue to rely
>> on David Edelsohn and Thomas Schwinge to back me up and help me with
>> some decision making along the way as my co-org-admins.
>
> I think that'd be good :) we've really appreciated all the work you've 
> done for the past editions.
>
> We'll be discussing project ideas with the rest of the gccrs team and 
> will update the page shortly. We'd love to mentor again this year.

Thanks a lot.  The organization registration ends February 6th, I guess
that is when the GSoC folks are going to start looking at applications
and idea lists.  So please consider that your deadline though of course
the earlier the better :-)

Thanks again,

Martin

[PATCH] ipa-cp: Fix check for exceeding param_ipa_cp_value_list_size (PR 113490)

[Martin Jambor]

Hi,

When the check for exceeding param_ipa_cp_value_list_size limit was
modified to be ignored for generating values from self-recursive
calls, it should have been changed from equal to, to equals toor is
greater than.  This omission manifests itself as PR 113490.

When I examined the condition I also noticed that the parameter should
come from the callee rather than the caller, since the value list is
associated with the former and not the latter.  In practice the limit
is of course very likely to be the same, but I fixed this aspect of
the condition too.  I briefly audited all other uses of opt_for_fn in
ipa-cp.cc and all the others looked OK.

Bootstrapped and tested on x86_64-linux.  OK for master?

Thanks,

Martin


gcc/ChangeLog:

2024-01-19  Martin Jambor  

PR ipa/113490
* ipa-cp.cc (ipcp_lattice::add_value): Bail out if value
count is equal or greater than the limit.  Use the limit from the
callee.

gcc/testsuite/ChangeLog:

2024-01-19  Martin Jambor  

PR ipa/113490
* gcc.dg/ipa/pr113490.c: New test.
---
 gcc/ipa-cp.cc   |  2 +-
 gcc/testsuite/gcc.dg/ipa/pr113490.c | 31 +
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr113490.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index b1e2a3a829a..e85477df32d 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -2298,7 +2298,7 @@ ipcp_lattice::add_value (valtype newval, 
cgraph_edge *cs,
return false;
   }
 
-  if (!same_lat_gen_level && values_count == opt_for_fn (cs->caller->decl,
+  if (!same_lat_gen_level && values_count >= opt_for_fn (cs->callee->decl,
param_ipa_cp_value_list_size))
 {
   /* We can only free sources, not the values themselves, because sources
diff --git a/gcc/testsuite/gcc.dg/ipa/pr113490.c 
b/gcc/testsuite/gcc.dg/ipa/pr113490.c
new file mode 100644
index 000..cffb0c5f639
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr113490.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -Wno-psabi"  } */
+
+typedef char A __attribute__((vector_size (64)));
+typedef short B __attribute__((vector_size (64)));
+typedef unsigned C __attribute__((vector_size (64)));
+typedef long D __attribute__((vector_size (64)));
+typedef __int128 E __attribute__((vector_size (64)));
+
+D bar1_D_0;
+E bar4 (A, D);
+
+E
+bar1 (C C_0)
+{
+  C_0 >>= 1;
+  bar4 ((A) C_0, bar1_D_0);
+  bar4 ((A) (E) {~0 }, (D) (A){ ~0 });
+  bar4 ((A) (B) { ~0 }, (D) (C) { ~0 });
+  bar1 ((C) (D){ 0, ~0});
+  bar4 ((A) C_0, bar1_D_0);
+  (A) { bar1 ((C) { 7})[5] - C_0[63], bar4 ((A) (D) {~0}, (D) (C) { 0, 
~0})[3]};
+}
+
+E
+bar4 (A A_0, D D_0)
+{
+  bar1 ((C) A_0);
+  bar1 ((C) {5});
+  bar1 ((C) D_0);
+}
-- 
2.43.0

[PATCH] sra: Disqualify bases of operands of asm gotos

[Martin Jambor]

Hi,

PR 110422 shows that SRA can ICE assuming there is a single edge
outgoing from a block terminated with an asm goto.  We need that for
BB-terminating statements so that any adjustments they make to the
aggregates can be copied over to their replacements.  Because we can't
have that after ASM gotos, we need to punt.

Bootstrapped and tested on x86_64-linux, OK for master?  It will need
some tweaking for release branches, is it in principle OK for them too
(after testing)?

Thanks,

Martin


gcc/ChangeLog:

2024-01-17  Martin Jambor  

PR tree-optimization/110422
* tree-sra.cc (scan_function): Disqualify bases of operands of asm
gotos.

gcc/testsuite/ChangeLog:

2024-01-17  Martin Jambor  

PR tree-optimization/110422
* gcc.dg/torture/pr110422.c: New test.
---
 gcc/testsuite/gcc.dg/torture/pr110422.c | 10 +
 gcc/tree-sra.cc | 29 -
 2 files changed, 33 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr110422.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr110422.c 
b/gcc/testsuite/gcc.dg/torture/pr110422.c
new file mode 100644
index 000..2e171a7a19e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr110422.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+
+struct T { int x; };
+int foo(void) {
+  struct T v;
+  asm goto("" : "+r"(v.x) : : : lab);
+  return 0;
+lab:
+  return -5;
+}
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 6a1141b7377..f8e71ec48b9 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1559,15 +1559,32 @@ scan_function (void)
case GIMPLE_ASM:
  {
gasm *asm_stmt = as_a  (stmt);
-   for (i = 0; i < gimple_asm_ninputs (asm_stmt); i++)
+   if (stmt_ends_bb_p (asm_stmt)
+   && !single_succ_p (gimple_bb (asm_stmt)))
  {
-   t = TREE_VALUE (gimple_asm_input_op (asm_stmt, i));
-   ret |= build_access_from_expr (t, asm_stmt, false);
+   for (i = 0; i < gimple_asm_ninputs (asm_stmt); i++)
+ {
+   t = TREE_VALUE (gimple_asm_input_op (asm_stmt, i));
+   disqualify_base_of_expr (t, "OP of asm goto.");
+ }
+   for (i = 0; i < gimple_asm_noutputs (asm_stmt); i++)
+ {
+   t = TREE_VALUE (gimple_asm_output_op (asm_stmt, i));
+   disqualify_base_of_expr (t, "OP of asm goto.");
+ }
  }
-   for (i = 0; i < gimple_asm_noutputs (asm_stmt); i++)
+   else
  {
-   t = TREE_VALUE (gimple_asm_output_op (asm_stmt, i));
-   ret |= build_access_from_expr (t, asm_stmt, true);
+   for (i = 0; i < gimple_asm_ninputs (asm_stmt); i++)
+ {
+   t = TREE_VALUE (gimple_asm_input_op (asm_stmt, i));
+   ret |= build_access_from_expr (t, asm_stmt, false);
+ }
+   for (i = 0; i < gimple_asm_noutputs (asm_stmt); i++)
+ {
+   t = TREE_VALUE (gimple_asm_output_op (asm_stmt, i));
+   ret |= build_access_from_expr (t, asm_stmt, true);
+ }
  }
  }
  break;
-- 
2.43.0

Re: [PATCH] sra: Partial fix for BITINT_TYPEs [PR113120]

[Martin Jambor]

Hi,
On Wed, Jan 10 2024, Jakub Jelinek wrote:
> Hi!
>
> As changed in other parts of the compiler, using
> build_nonstandard_integer_type is not appropriate for arbitrary precisions,
> especially if the precision comes from a BITINT_TYPE or something based on
> that, build_nonstandard_integer_type relies on some integral mode being
> supported that can support the precision.
>
> The following patch uses build_bitint_type instead for BITINT_TYPE
> precisions.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Note, it would be good if we were able to punt on the optimization
> (but this code doesn't seem to be able to punt, so it needs to be done
> somewhere earlier) at least in cases where building it would be invalid.
> E.g. right now BITINT_TYPE can support precisions up to 65535 (inclusive),
> but 65536 will not work anymore (we can't have > 16-bit TYPE_PRECISION).
> I've tried to replace 513 with 65532 in the testcase and it didn't ICE,
> so maybe it ran into some other SRA limit.

Thank you very much for the patch.  Regarding punting, did you mean for
all BITINT_TYPEs or just for big ones, like you did when you fixed PR
11333 (thanks for that too) or something entirely else?

Martin

>
> 2024-01-10  Jakub Jelinek  
>
>   PR tree-optimization/113120
>   * tree-sra.cc (analyze_access_subtree): For BITINT_TYPE
>   with root->size TYPE_PRECISION don't build anything new.
>   Otherwise, if root->type is a BITINT_TYPE, use build_bitint_type
>   rather than build_nonstandard_integer_type.
>
>   * gcc.dg/bitint-63.c: New test.

[PATCH] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

[Martin Jambor]

Hi,

PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.

I have already fixed this for unused parameters in callees, this bug
shows that almost the same thing can happen for removed returns, on
the side of callers.  This means that the issue has to be fixed
elsewhere, in call redirection.  This patch adds a function which
looks for (and through, using a work-list) uses of operations fed
specific SSA names and removes them all.

That would have been easy if it wasn't for debug statements during
tree-inline (from which call redirection is also invoked).  Debug
statements are decoupled from the rest at this point and iterating
over uses of SSAs does not bring them up.  During tree-inline they are
handled especially at the end, I assume in order to make sure that
relative ordering of UIDs are the same with and without debug info.

This means that during tree-inline we need to make a hash of killed
SSAs, that we already have in copy_body_data, available to the
function making the purging.  So the patch duly does also that, making
the interface slightly ugly.  Moreover, all newly unused SSA names
need to be freed and as PR 112616 showed, it must be done in a defined
order, which is what newly added ipa_release_ssas_in_hash does.

The only difference from the patch which has already been approved in
September but which I later had to revert is (one function name and)
that SSAs that are to be released are first put into an auto_vec and
sorted according their version number to avoid issues like PR 112616.

The patch has passed bootstrap, LTO-bootstrap and profiled-LTO-bootstrap
and testing on x86_64-linux, bootstrap, LTO-bootstrap and testing on
ppc64le-linux and bootstrap and LTO-bootstrap on Aarch64, testsuite
there is still running, OK if it passes?

Thanks

Martin


gcc/ChangeLog:

2024-01-12  Martin Jambor  

PR ipa/108007
PR ipa/112616
* cgraph.h (cgraph_edge): Add a parameter to
redirect_call_stmt_to_callee.
* ipa-param-manipulation.h (ipa_param_adjustments): Add a
parameter to modify_call.
(ipa_release_ssas_in_hash): Declare.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
parameter killed_ssas, pass it to padjs->modify_call.
* ipa-param-manipulation.cc (purge_all_uses): New function.
(ipa_param_adjustments::modify_call): New parameter killed_ssas.
Instead of substituting uses, invoke purge_all_uses.  If
hash of killed SSAs has not been provided, create a temporary one
and release SSAs that have been added to it.
(compare_ssa_versions): New function.
(ipa_release_ssas_in_hash): Likewise.
* tree-inline.cc (redirect_all_calls): Create
id->killed_new_ssa_names earlier, pass it to edge redirection,
adjust a comment.
(copy_body): Release SSAs in id->killed_new_ssa_names.

gcc/testsuite/ChangeLog:

2024-01-15  Martin Jambor  

PR ipa/108007
PR ipa/112616
* gcc.dg/ipa/pr108007.c: New test.
* gcc.dg/ipa/pr112616.c: Likewise.
---
 gcc/cgraph.cc   |  10 ++-
 gcc/cgraph.h|   9 ++-
 gcc/ipa-param-manipulation.cc   | 112 ++--
 gcc/ipa-param-manipulation.h|   5 +-
 gcc/testsuite/gcc.dg/ipa/pr108007.c |  32 
 gcc/testsuite/gcc.dg/ipa/pr112616.c |  28 +++
 gcc/tree-inline.cc  |  27 ---
 7 files changed, 184 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr108007.c
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr112616.c

diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
index d565c005f62..0ac8f73204b 100644
--- a/gcc/cgraph.cc
+++ b/gcc/cgraph.cc
@@ -1403,11 +1403,17 @@ cgraph_edge::redirect_callee (cgraph_node *n)
speculative indirect call, remove "speculative" of the indirect call and
also redirect stmt to it's final direct target.
 
+   When called from within tree-inline, KILLED_SSAs has to contain the pointer
+   to killed_new_ssa_names within the copy_body_data structure and SSAs
+   discovered to be useless (if LHS is removed) will be added to it, otherwise
+   it needs to be NULL.
+
It is up to caller to iteratively transform each "speculative"
direct call as appropriate.  */
 
 gimple *
-cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
+cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e,
+  hash_set  *killed_ssas)
 {
   tree decl = gimple_call_fndecl (e->call_stmt);
   gcall *new_stmt;
@@ -1527,7 +1533,7 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge *e)
remove_stmt_from_eh_lp (e->call_stmt);
 
   tree old_fntype = gimple_call_fntype (e-&

GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

another year has passed, Google has announced there will be again Google
Summer of Code (GsoC) in 2024 and the deadline for organizations to
apply is already approaching (February 6th).  I'd like to volunteer to
be the main org-admin for GCC again but let me know if you think I
shouldn't or that someone else should or if you want to do it instead.
Otherwise I'll assume that I will and I hope that I can continue to rely
on David Edelsohn and Thomas Schwinge to back me up and help me with
some decision making along the way as my co-org-admins.

 The most important bit: 

I would like to ask all (moderately) seasoned GCC contributors to
consider mentoring a contributor this year and ideally also come up with
a project that they would like to lead.  I'm collecting proposal on our
wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
to the top list there.  Or, if you are unsure, post your offer and
project idea as a reply here to the mailing list.

Additionally, if you have added an idea to the list in the recent years,
please review it whether it is still up-to-date or needs adjusting or
should be removed altogether.

=

At this point, we need to collect list of project ideas.  Eventually,
each listed project idea should have:

  a) a project title,
  b) more detailed description of the project (2-5 sentences),
  c) expected outcomes (we do have a catch-almost-all formulation that
 outcome is generally patches at the bottom of the list on the
 wiki),
  d) skills required/preferred,
  e) project size - whether it is expected to take approximately 350,
 175 or just 90 hours (the last option in new in 2024, see below),
  f) difficulty (easy, hard or medium, but we don't really have easy
 projects), and
  g) expected mentors.

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one or ideally two.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you have always done in the past.

As far as I know, GSoC 2024 should be quite similar to the last year,
the most important parameters probably are these:

  - Contributors (formerly students) must either be full-time students
or be "beginners to open source."

  - There are now three project sizes: roughly 90 hors (small), roughly
175 hours (medium-sized) and roughly 350 hours (large) of work in
total.  The small option is new this year but because our projects
usually have a lengthy learning period, I think we will usually want
to stick to the medium and large variants.

  - Timing should be pretty much as flexible as last year.  The
recommended "standard" duration is 12 weeks but depending on
contributor's and mentor's needs and circumstances, projects can
take anywhere between 10 and 22 weeks.  There will be one mid-term
and one final evaluation.

For further details you can see:

  - The announcement of GSoC 2024:

https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html

  - GSoC rules:
https://summerofcode.withgoogle.com/rules

  - The detailed GSoC 2024 timeline:
https://developers.google.com/open-source/gsoc/timeline

  - Elaborate project idea guidelines:
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

Thank you very much for your participation and help.  Let's hope we
attract some great contributors again this year.

Martin

GCC GSoC 2024: Call for project ideas and mentors

[Martin Jambor]

Hello,

another year has passed, Google has announced there will be again Google
Summer of Code (GsoC) in 2024 and the deadline for organizations to
apply is already approaching (February 6th).  I'd like to volunteer to
be the main org-admin for GCC again but let me know if you think I
shouldn't or that someone else should or if you want to do it instead.
Otherwise I'll assume that I will and I hope that I can continue to rely
on David Edelsohn and Thomas Schwinge to back me up and help me with
some decision making along the way as my co-org-admins.

 The most important bit: 

I would like to ask all (moderately) seasoned GCC contributors to
consider mentoring a contributor this year and ideally also come up with
a project that they would like to lead.  I'm collecting proposal on our
wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours
to the top list there.  Or, if you are unsure, post your offer and
project idea as a reply here to the mailing list.

Additionally, if you have added an idea to the list in the recent years,
please review it whether it is still up-to-date or needs adjusting or
should be removed altogether.

=

At this point, we need to collect list of project ideas.  Eventually,
each listed project idea should have:

  a) a project title,
  b) more detailed description of the project (2-5 sentences),
  c) expected outcomes (we do have a catch-almost-all formulation that
 outcome is generally patches at the bottom of the list on the
 wiki),
  d) skills required/preferred,
  e) project size - whether it is expected to take approximately 350,
 175 or just 90 hours (the last option in new in 2024, see below),
  f) difficulty (easy, hard or medium, but we don't really have easy
 projects), and
  g) expected mentors.

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one or ideally two.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you have always done in the past.

As far as I know, GSoC 2024 should be quite similar to the last year,
the most important parameters probably are these:

  - Contributors (formerly students) must either be full-time students
or be "beginners to open source."

  - There are now three project sizes: roughly 90 hors (small), roughly
175 hours (medium-sized) and roughly 350 hours (large) of work in
total.  The small option is new this year but because our projects
usually have a lengthy learning period, I think we will usually want
to stick to the medium and large variants.

  - Timing should be pretty much as flexible as last year.  The
recommended "standard" duration is 12 weeks but depending on
contributor's and mentor's needs and circumstances, projects can
take anywhere between 10 and 22 weeks.  There will be one mid-term
and one final evaluation.

For further details you can see:

  - The announcement of GSoC 2024:

https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html

  - GSoC rules:
https://summerofcode.withgoogle.com/rules

  - The detailed GSoC 2024 timeline:
https://developers.google.com/open-source/gsoc/timeline

  - Elaborate project idea guidelines:
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

Thank you very much for your participation and help.  Let's hope we
attract some great contributors again this year.

Martin

Re: lambda coding style

[Martin Jambor]

Hi,

On Thu, Jan 11 2024, Jason Merrill wrote:
> On 1/11/24 12:48, Martin Jambor wrote:
>> On Wed, Jan 10 2024, Jason Merrill via Gcc wrote:
>>> What formatting style do we want for non-trivial lambdas in GCC sources?
>>>I'm thinking the most consistent choice would be
>>>
>>> auto l = [&] (parms) // space between ] (
>>> {  // brace on new line, indented two spaces
>>>   return stuff;
>>> };
>>>
>>> By default, recent emacs lines up the { with the previous line, like an
>>> in-class function definition; I talked it into the above indentation with
>>>
>>> (defun lambda-offset (elem)
>>> (if (assq 'inline-open c-syntactic-context) '+ 0))
>>> (add-to-hook 'c++-mode-hook '(c-set-offset 'inlambda 'lambda-offset))
>> 
>> Is this really add-to-hook and not add-hook?
>
> Oops! add-to-hook is a custom variant I wrote back in like 1992; for 
> add-hook you'll want
>
> (add-hook 'c++-mode-hook
>'(lambda () (c-set-offset 'inlambda 'lambda-offset)))
>

I see, thanks!

Martin

Re: lambda coding style

[Martin Jambor]

Hi,

On Wed, Jan 10 2024, Jason Merrill via Gcc wrote:
> What formatting style do we want for non-trivial lambdas in GCC sources? 
>   I'm thinking the most consistent choice would be
>
> auto l = [&] (parms) // space between ] (
>{  // brace on new line, indented two spaces
>  return stuff;
>};
>
> By default, recent emacs lines up the { with the previous line, like an 
> in-class function definition; I talked it into the above indentation with
>
> (defun lambda-offset (elem)
>(if (assq 'inline-open c-syntactic-context) '+ 0))
> (add-to-hook 'c++-mode-hook '(c-set-offset 'inlambda 'lambda-offset))

Is this really add-to-hook and not add-hook?

Thanks!

Martin

>
> I think we probably want the same formatting for lambdas in function 
> argument lists, e.g.
>
> algorithm ([] (parms)
>{
>  return foo;
>});
>
> Any other opinions?
>
> Jason

Re: [wwwdocs] gcc-14/changes.html: OpenMP - improve wording

[Martin Jambor]

Hi Tobias,

On Mon, Jan 08 2024, Tobias Burnus wrote:
> The attached patch

there was no patch attached to your message.

Martin

> does a tiny updated to the OpenMP features (AMD GCN 
> now also has an optimized memcpy_rect not only nvptx), but the main 
> change is some shifting around to make it more consistent and better 
> readable.
>
> I intend to commit this relatively soon; like always, comments and 
> suggestions are welcome - be it before or after the commit.
>
> Current version: http://gcc.gnu.org/gcc-14/changes.html
>
> Thanks,
>
> Tobias

Re: Update on GCC 14 C type safety changes/warnings as errors

[Martin Jambor]

Hello,

On Thu, Nov 30 2023, Florian Weimer via Gcc wrote:
> The patch series is currently under review:
>
>   [PATCH v3 00/11] : More warnings as errors by default
>   
> 
>
> Jeff as a global reviewer has delegated review to Marek.
>
> The current series is based on an earlier suggestion to do as much as
> possible in one transition.  The full list of upgraded warnings is:
>
>   -Wimplicit-function-declaration
>   -Wimplicit-int
>   -Wint-conversion
>   -Wreturn-mismatch (new, previously part of -Wreturn-types)
>   -Wdeclaration-missing-parameter-type (new, previously unnamed)
>   -Wincompatible-pointer-types

[...]

>
> Thoughts?
>

First and foremost, thanks a lot for working on this and especially for
starting with the enormous task of dealing with the fallout.

Given you probably have the most experience with it, can you please also
suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
would describe this change?  (I was thinking of proposing something
myself, but I don't really know just how much verbose such an entry
should be.)

Thanks!

Martin

Re: [PATCH] tree-optimization/111807 - ICE in verify_sra_access_forest

[Martin Jambor]

  1577701 are aritificially in conflict with void *

  Modref stats:
modref kill: 832 kills, 19399 queries
modref use: 50760 disambiguations, 1825109 queries
modref clobber: 1371014 disambiguations, 40152535 queries
5190238 tbaa queries (0.129263 per modref query)
1341663 base compares (0.033414 per modref query)

  PTA query stats:
pt_solution_includes: 36784427 disambiguations, 46141175 queries
pt_solutions_intersect: 4519387 disambiguations, 17081996 queries

to:

  Alias oracle query stats:
refs_may_alias_p: 94354083 disambiguations, 106278948 queries
ref_maybe_used_by_call_p: 1572511 disambiguations, 95618018 queries
call_may_clobber_ref_p: 649273 disambiguations, 659371 queries
stmt_kills_ref_p: 142342 kills, 8407310 queries
nonoverlapping_component_refs_p: 19 disambiguations, 10227 queries
nonoverlapping_refs_since_match_p: 15665 disambiguations, 52585 must 
overlaps, 68893 queries
aliasing_component_refs_p: 67104 disambiguations, 3081781 queries
TBAA oracle: 22676608 disambiguations 61782455 queries
 14044948 are in alias set 0
 10998619 queries asked about the same object
 153 queries asked about the same alias set
 0 access volatile
 12484882 are dependent in the DAG
 1577245 are aritificially in conflict with void *

  Modref stats:
modref kill: 832 kills, 19399 queries
modref use: 50760 disambiguations, 1825106 queries
modref clobber: 1371028 disambiguations, 40152504 queries
5190319 tbaa queries (0.129265 per modref query)
1341403 base compares (0.033408 per modref query)

  PTA query stats:
pt_solution_includes: 36784449 disambiguations, 46141210 queries
    pt_solutions_intersect: 4519320 disambiguations, 17082083 queries

gcc/ChangeLog:

2023-12-13  Martin Jambor  

PR tree-optimization/111807
* tree-sra.cc (build_ref_for_model): Allow offset smaller than
model->offset when gsi is non-NULL.  Adjust function comment.
---
 gcc/tree-sra.cc | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 3bd0c7a9af0..1dba721be11 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1843,8 +1843,11 @@ build_reconstructed_reference (location_t, tree base, 
struct access *model)
 /* Construct a memory reference to a part of an aggregate BASE at the given
OFFSET and of the same type as MODEL.  In case this is a reference to a
bit-field, the function will replicate the last component_ref of model's
-   expr to access it.  GSI and INSERT_AFTER have the same meaning as in
-   build_ref_for_offset.  */
+   expr to access it.  INSERT_AFTER and GSI have the same meaning as in
+   build_ref_for_offset, furthermore, when GSI is NULL, the function expects
+   that it re-builds the entire reference from a DECL to the final access and
+   so will create a MEM_REF when OFFSET does not exactly match offset of
+   MODEL.  */
 
 static tree
 build_ref_for_model (location_t loc, tree base, HOST_WIDE_INT offset,
@@ -1874,7 +1877,8 @@ build_ref_for_model (location_t loc, tree base, 
HOST_WIDE_INT offset,
  && !TREE_THIS_VOLATILE (base)
  && (TYPE_ADDR_SPACE (TREE_TYPE (base))
  == TYPE_ADDR_SPACE (TREE_TYPE (model->expr)))
- && offset == model->offset
+ && (offset == model->offset
+ || (gsi && offset <= model->offset))
  /* build_reconstructed_reference can still fail if we have already
 massaged BASE because of another type incompatibility.  */
  && (res = build_reconstructed_reference (loc, base, model)))
-- 
2.43.0

[PATCH] SRA: Force gimple operand in an additional corner case (PR 112822)

[Martin Jambor]

Hi,

PR 112822 revealed a corner case in load_assign_lhs_subreplacements
where it creates invalid gimple: an assignment where on the LHS there
is a complex variable which however is not a gimple register because
it has partial defs and on the right hand side there is a
VIEW_CONVERT_EXPR.  This patch invokes force_gimple_operand_gsi on
such statements (like it already does when both sides of a generated
assignment have partial definitions.

I've made sure the patch passes bootstrap and testsuite on x86_64-linux,
the bug reporter was kind enough to also check the same on an
powerpc64le-linux (see bugzilla comment #8).

The testcase has reasonable size but it is specific to ppc64le and its
altivec vectors.  My plan is to ask the bug reporter to massage it into
a target specific testcase in bugzilla.  Alternatively I can try to
craft a testcase from scratch but that will take time.

Despite the above, is the patch OK for master?

Thanks,

Martin



gcc/ChangeLog:

2023-12-12  Martin Jambor  

PR tree-optimization/112822
* tree-sra.cc (load_assign_lhs_subreplacements): Invoke
force_gimple_operand_gsi also when LHS has partial stores and RHS is a
VIEW_CONVERT_EXPR.
---
 gcc/tree-sra.cc | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 3bd0c7a9af0..99a1b0a6d17 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -4219,11 +4219,15 @@ load_assign_lhs_subreplacements (struct access *lacc,
  if (racc && racc->grp_to_be_replaced)
{
  rhs = get_access_replacement (racc);
+ bool vce = false;
  if (!useless_type_conversion_p (lacc->type, racc->type))
-   rhs = fold_build1_loc (sad->loc, VIEW_CONVERT_EXPR,
-  lacc->type, rhs);
+   {
+ rhs = fold_build1_loc (sad->loc, VIEW_CONVERT_EXPR,
+lacc->type, rhs);
+ vce = true;
+   }
 
- if (racc->grp_partial_lhs && lacc->grp_partial_lhs)
+ if (lacc->grp_partial_lhs && (vce || racc->grp_partial_lhs))
rhs = force_gimple_operand_gsi (>old_gsi, rhs, true,
NULL_TREE, true, GSI_SAME_STMT);
}
-- 
2.43.0

Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates

[Martin Jambor]

Hi,

On Tue, Nov 28 2023, Jan Hubicka wrote:
>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>> 
>> > On Tue, Nov 28 2023, Richard Biener wrote:
>> > > On Mon, 27 Nov 2023, Martin Jambor wrote:
>> > >
>> > >> Hi,
>> > >> 
>> > >> The enhancement to address PR 109849 contained an importsnt thinko,
>> > >> and that any reference that is passed to a function and does not
>> > >> escape, must also not happen to be aliased by the return value of the
>> > >> function.  This has quickly transpired as bugs PR 112711 and PR
>> > >> 112721.
>> > >> 
>> > >> Just as IPA-modref does a good enough job to allow us to rely on the
>> > >> escaped set of variables, it sems to be doing well also on updating
>> > >> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
>> > >> exactly the situation we need to avoid.  Of course, if a call
>> > >> statement ignores any returned value, we also do not need to check the
>> > >> flag.
>> > >
>> > > But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
>> > > verify the parameter doesn't escape through the return at all?
>> > >
>> > 
>> > I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
>> > param->next" but those are not a problem (whatever next points to cannot
>> > be an SRA candidate and any ADDR_EXPR storing its address there would
>> > trigger a disqualification or at least an assert).  But I guess I am
>> > wrong, what is actually the exact meaning of the flag?
>> 
>> I thought it's return (x.ptr = param, );
>> 
>> so the parameter is reachable from the return value.
>> 
>> But let's Honza answer...
> It is same difference as direct/indirect escape. so it check whether
> values pointed to by arg can be possibly returned.  Indeed maybe we
> should think of better name - the other interpretation did not even
> occur to me, but it makes sense.
>

Is my patch OK then?

(Apart from making one of the testcases x86_64-only, as Andrew pointed
out, which I wanted to do but the line somehow got lost.  Making the
testcase more general is fairly low on my contested TODO list and the
testing depends on a specific instruction trapping.)

Thanks,

Martin

Re: [PATCH] tree-sra: Avoid returns of references to SRA candidates

[Martin Jambor]

On Tue, Nov 28 2023, Richard Biener wrote:
> On Mon, 27 Nov 2023, Martin Jambor wrote:
>
>> Hi,
>> 
>> The enhancement to address PR 109849 contained an importsnt thinko,
>> and that any reference that is passed to a function and does not
>> escape, must also not happen to be aliased by the return value of the
>> function.  This has quickly transpired as bugs PR 112711 and PR
>> 112721.
>> 
>> Just as IPA-modref does a good enough job to allow us to rely on the
>> escaped set of variables, it sems to be doing well also on updating
>> EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
>> exactly the situation we need to avoid.  Of course, if a call
>> statement ignores any returned value, we also do not need to check the
>> flag.
>
> But what about EAF_NOT_RETURNED_INDIRECTLY?  Don't you need to
> verify the parameter doesn't escape through the return at all?
>

I thought EAF_NOT_RETURNED_INDIRECTLY prohibits things like "return
param->next" but those are not a problem (whatever next points to cannot
be an SRA candidate and any ADDR_EXPR storing its address there would
trigger a disqualification or at least an assert).  But I guess I am
wrong, what is actually the exact meaning of the flag?

Thanks,

Martin

[PATCH] tree-sra: Avoid returns of references to SRA candidates

[Martin Jambor]

Hi,

The enhancement to address PR 109849 contained an importsnt thinko,
and that any reference that is passed to a function and does not
escape, must also not happen to be aliased by the return value of the
function.  This has quickly transpired as bugs PR 112711 and PR
112721.

Just as IPA-modref does a good enough job to allow us to rely on the
escaped set of variables, it sems to be doing well also on updating
EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
exactly the situation we need to avoid.  Of course, if a call
statement ignores any returned value, we also do not need to check the
flag.

Hopefully this does not pessimize things too much, I have verified
that the PR 109849 testcae remains quick and so should also the
benchmark it is derived from.

The patch has passed bootstrap and testing on x86_64-linux, OK for
master?

Thanks,

Martin


gcc/ChangeLog:

2023-11-27  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* tree-sra.cc (build_access_from_call_arg): New parameter
CAN_BE_RETURNED, disqualify any candidate passed by reference if it is
true.  Adjust leading comment.
(scan_function): Pass appropriate value to CAN_BE_RETURNED of
build_access_from_call_arg.

gcc/testsuite/ChangeLog:

2023-11-27  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* g++.dg/tree-ssa/pr112711.C: New test.
* gcc.dg/tree-ssa/pr112721.c: Likewise.
---
 gcc/testsuite/g++.dg/tree-ssa/pr112711.C | 31 ++
 gcc/testsuite/gcc.dg/tree-ssa/pr112721.c | 26 +++
 gcc/tree-sra.cc  | 40 ++--
 3 files changed, 88 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/pr112711.C
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr112721.c

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr112711.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
new file mode 100644
index 000..c04524b04a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr112711.C
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-O1" } */
+
+typedef  int i32;
+typedef unsigned int u32;
+
+static inline void write_i32(void *memory, i32 value) {
+  // swap i32 bytes as if it was u32:
+  u32 u_value = value;
+  value = __builtin_bswap32(u_value);
+
+  // llvm infers '1' alignment from destination type
+  __builtin_memcpy(__builtin_assume_aligned(memory, 1), , sizeof(value));
+}
+
+__attribute__((noipa))
+static void bug (void) {
+  #define assert_eq(lhs, rhs) if (lhs != rhs) __builtin_trap()
+
+  unsigned char data[5];
+  write_i32(data, -1362446643);
+  assert_eq(data[0], 0xAE);
+  assert_eq(data[1], 0xCA);
+  write_i32(data + 1, -1362446643);
+  assert_eq(data[1], 0xAE);
+}
+
+int main() {
+bug();
+return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
new file mode 100644
index 000..adf62613266
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr112721.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options "-O1" } */
+
+unsigned * volatile gv;
+
+struct a {
+  int b;
+};
+int c, e;
+long d;
+unsigned * __attribute__((noinline))
+f(unsigned *g) {
+  for (; c;)
+e = d;
+  return gv ? gv : g;
+}
+int main() {
+  int *h;
+  struct a i = {8};
+  int *j = 
+  h = (unsigned *) f(j);
+  *h = 0;
+  if (i.b != 0)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 3a0d52675fe..6a759783990 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1268,18 +1268,27 @@ abnormal_edge_after_stmt_p (gimple *stmt, enum 
out_edge_check *oe_check)
 }
 
 /* Scan expression EXPR which is an argument of a call and create access
-   structures for all accesses to candidates for scalarization.  Return true if
-   any access has been inserted.  STMT must be the statement from which the
-   expression is taken.  */
+   structures for all accesses to candidates for scalarization.  Return true
+   if any access has been inserted.  STMT must be the statement from which the
+   expression is taken.  CAN_BE_RETURNED must be true if call argument flags
+   do not rule out that the argument is directly returned.  OE_CHECK is used
+   to remember result of a test for abnormal outgoing edges after this
+   statement.  */
 
 static bool
-build_access_from_call_arg (tree expr, gimple *stmt,
+build_access_from_call_arg (tree expr, gimple *stmt, bool can_be_returned,
enum out_edge_check *oe_check)
 {
   if (TREE_CODE (expr) == ADDR_EXPR)
 {
   tree base = get_base_address (TREE_OPERAND (expr, 0));
 
+  if (can_be_returned)
+   {
+ disqualify_base_of_expr (base, "Address possibly returned, "
+  "leading to an alis SRA may not know.");
+ return false;
+   }
   if (ab

Re: [PATCH] sra: SRA of non-escaped aggregates passed by reference to calls

[Martin Jambor]

Hello,

thanks a lot for your review.

On Fri, Nov 17 2023, Richard Biener wrote:
> On Thu, 16 Nov 2023, Martin Jambor wrote:
>
>> Hello,
>> 
>> PR109849 shows that a loop that heavily pushes and pops from a stack
>> implemented by a C++ std::vec results in slow code, mainly because the
>> vector structure is not split by SRA and so we end up in many loads
>> and stores into it.  This is because it is passed by reference
>> to (re)allocation methods and so needs to live in memory, even though
>> it does not escape from them and so we could SRA it if we
>> re-constructed it before the call and then separated it to distinct
>> replacements afterwards.
>> 
>> This patch does exactly that, first relaxing the selection of
>> candidates to also include those which are addressable but do not
>> escape and then adding code to deal with the calls.  The
>> micro-benchmark that is also the (scan-dump) testcase in this patch
>> runs twice as fast with it than with current trunk.  Honza measured
>> its effect on the libjxl benchmark and it almost closes the
>> performance gap between Clang and GCC while not requiring excessive
>> inlining and thus code growth.
>> 
>> The patch disallows creation of replacements for such aggregates which
>> are also accessed with a precision smaller than their size because I
>> have observed that this led to excessive zero-extending of data
>> leading to slow-downs of perlbench (on some CPUs).  Apart from this
>> case I have not noticed any regressions, at least not so far.
>> 
>> Gimple call argument flags can tell if an argument is unused (and then
>> we do not need to generate any statements for it) or if it is not
>> written to and then we do not need to generate statements loading
>> replacements from the original aggregate after the call statement.
>> Unfortunately, we cannot symmetrically use flags that an aggregate is
>> not read because to avoid re-constructing the aggregate before the
>> call because flags don't tell which what parts of aggregates were not
>> written to, so we load all replacements, and so all need to have the
>> correct value before the call.
>> 
>> The patch passes bootstrap, lto-bootstrap and profiled-lto-bootstrap on
>> x86_64-linux and a very similar patch has also passed bootstrap and
>> testing on Aarch64-linux and ppc64le-linux (I'm re-running both on these
>> two architectures but as I'm sending this).  OK for master?
>> 
>> Thanks,
>> 
>> Martin
>> 

[...]

>> @@ -1920,10 +1981,19 @@ maybe_add_sra_candidate (tree var)
>>reject (var, "not aggregate");
>>return false;
>>  }
>> -  /* Allow constant-pool entries that "need to live in memory".  */
>> -  if (needs_to_live_in_memory (var) && !constant_decl_p (var))
>> +
>> +  if ((is_global_var (var)
>> +   /* There are cases where non-addressable variables fail the
>> +  pt_solutions_check test, e.g in gcc.dg/uninit-40.c. */
>> +   || (TREE_ADDRESSABLE (var)
>> +   && pt_solution_includes (>gimple_df->escaped, var))
>
> so it seems this is the "correctness" test rather than using
> the call argument flags?  I'll note that this may be overly
> conservative.

It is but with ipa-modref it seems to work fairly well.

>
> For the call handling above I wondered about return-slot-opt calls
> where the address of the LHS escapes to the call - if the points-to
> check is the correctness check that should still work out of course
> (but subject to PR109945).

Hm, I wonder what the implications of that PR is for SRA, but it is a
different issue, this patch does not touch handling LHSs.

>
>> +   || (TREE_CODE (var) == RESULT_DECL
>> +   && !DECL_BY_REFERENCE (var)
>> +   && aggregate_value_p (var, current_function_decl)))
>> +  /* Allow constant-pool entries that "need to live in memory".  */
>> +  && !constant_decl_p (var))
>>  {
>> -  reject (var, "needs to live in memory");
>> +  reject (var, "needs to live in memory and escapes or global");
>>return false;
>>  }
>>if (TREE_THIS_VOLATILE (var))
>> @@ -2122,6 +2192,21 @@ sort_and_splice_var_accesses (tree var)
>>  gcc_assert (access->offset >= low
>>  && access->offset + access->size <= high);
>>  
>> +  if (INTEGRAL_TYPE_P (access->type)
>> +  && TYPE_PRECISION (access->type) != access->size
>> +  && bitmap

Re: libstdc++: Speed up push_back

[Martin Jambor]

Hello,

On Thu, Nov 23 2023, Jonathan Wakely wrote:
> On Thu, 23 Nov 2023 at 15:34, Jan Hubicka  wrote:
>>

[...]

>>
>> I also wonder, if default operator new and malloc can be handled as not
>> reading/modifying anything visible to the user code.
>
> No, there's no way to know if the default operator new is being used.
> A replacement operator new could be provided at link-time.
>
> That's why we need -fsane-operator-new
>

Would it make sense to add -fsane-operator-new to -Ofast?

Martin

[PATCH] Bump LTO_minor_version

[Martin Jambor]

Hi Richi,

On Wed, Sep 20 2023, Richard Biener wrote:
> The following turns MAX_NUM_CHAINS and MAX_CHAIN_LEN to params which
> allows to experiment with raising them.  For the testcase in PR111489
> raising MAX_CHAIN_LEN from 5 to 8 avoids the bogus diagnostics
> at -O2, at -O3 we need a MAX_CHAIN_LEN of 6.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
>
>   PR tree-optimization/111489
>   * doc/invoke.texi (--param uninit-max-chain-len): Document.
>   (--param uninit-max-num-chains): Likewise.
>   * params.def (-param=uninit-max-chain-len=): New.
>   (-param=uninit-max-num-chains=): Likewise.
>   * gimple-predicate-analysis.cc (MAX_NUM_CHAINS): Define to
>   param_uninit_max_num_chains.
>   (MAX_CHAIN_LEN): Define to param_uninit_max_chain_len.
>   (uninit_analysis::init_use_preds): Avoid VLA.
>   (uninit_analysis::init_from_phi_def): Likewise.
>   (compute_control_dep_chain): Avoid using MAX_CHAIN_LEN in
>   template parameter.

our test attempting to detect that LTO_minor_version should have been
bumped but wasn't is failing and eye-balling backports to the gcc-13
branch, this looks like a likely culprit?  Unless I am mistaken, params
are streamed and therefore they alter the LTO format?

If so, I'd like to propose the obvious fix, OK for gcc-13 (after some
testing)?

Thanks,

Martin


[PATCH] Bump LTO_minor_version

I believe r13-8039-g06ee3438a4fcf9 has changed LTO format and
therefore we should bump the minor version of the GCC 13 LTO format.

gcc/ChangeLog:

2023-11-20  Martin Jambor  

* lto-streamer.h (LTO_minor_version): Bump.
---
 gcc/lto-streamer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
index fc7133d07ba..75cebcd02d3 100644
--- a/gcc/lto-streamer.h
+++ b/gcc/lto-streamer.h
@@ -122,7 +122,7 @@ along with GCC; see the file COPYING3.  If not see
  form followed by the data for the string.  */
 
 #define LTO_major_version GCC_major_version
-#define LTO_minor_version 0
+#define LTO_minor_version 1
 
 typedef unsigned char  lto_decl_flags_t;
 
-- 
2.42.0