date:20220403

Re: [PATCH v4] libgo: Don't use pt_regs member in mcontext_t

2022-04-03 Thread Sören Tempel via Gcc-patches

Ian Lance Taylor  wrote:
> Sorry, I guess I misread your patch.

No problem, I think this stuff is hard to get right and understand in
general since it is so poorly documented.

> What is the right standalone code for the PPC64 musl case?  Thanks.

In order to have the current code (i.e. current gofrontend HEAD with
your patch) compile and work with PPC64 musl it would be sufficient to
just include asm/ptrace.h, as proposed in the v1 of my patch [1]:

// On PowerPC, ucontext.h uses a pt_regs struct as an incomplete
// type. This type must be completed by including asm/ptrace.h.
#ifdef __PPC__
#include 
#endif

Technically, this should also be needed for using .regs on glibc since
it also declares pt_regs as in incomplete type [5]. As such, adding the
include may be the easiest way to resolve this issue.

However, based on your feedback [2] and feedback by Rich Felker [3]. I
rewrote the go-signal.c PowerPC register handling code to not use .regs
("Having pt_regs appear at all in code not using ptrace is a serious
code smell"). See the v4 of my patch for details [4]. If you don't want
to use .regs on PPC64 musl the right standalone code should be:

((ucontext_t*)(context))->uc_mcontext.gp_regs;

Unfortunately, this code only works on PPC64 musl and PPC64 glibc not on
PPC32 glibc and PPC32 musl, thus I added a case distinction in the v4 of
my patch [4]. For my personal needs it would be very much sufficient to
just add an include of asm/ptrace.h to go-signal.c to make the current
code (i.e. your patch) also work with PPC64 musl.

Greetings,
Sören

[1]: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587520.html
[2]: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590668.html
[3]: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591257.html
[4]: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591593.html
[5]: 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/powerpc/sys/ucontext.h;hb=6ff3c7714900529b8f5ca64b58d5da9cd5d5b345#l33

[committed] d: Remove Wtemplates warnings from the code generation pass

2022-04-03 Thread Iain Buclaw via Gcc-patches

Hi,

This patch removes the `-Wtemplate' warnings from the code generation
pass of the D front-end.

These have been superceded by the upstream front-end's own internal
tracking of instantiations, exposed by `-ftransition=templates'.

Bootstrapped on x86_64-linux-gnu, and committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-lang.cc: Include dmd/template.h.
(d_parse_file): Call printTemplateStats when vtemplates is set.
* decl.cc (start_function): Remove OPT_Wtemplates warning.
* lang.opt (Wtemplates): Remove.
---
 gcc/d/d-lang.cc |  4 
 gcc/d/decl.cc   | 11 +--
 gcc/d/lang.opt  |  4 
 3 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index 4a7aa8983b7..69571628336 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -33,6 +33,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "dmd/module.h"
 #include "dmd/mtype.h"
 #include "dmd/target.h"
+#include "dmd/template.h"
 
 #include "opts.h"
 #include "alias.h"
@@ -1306,6 +1307,9 @@ d_parse_file (void)
}
 }
 
+  if (global.params.vtemplates)
+printTemplateStats ();
+
   /* Generate JSON files.  */
   if (global.params.doJsonGeneration)
 {
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index ea8baef588c..86ea1761f4f 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -1891,16 +1891,7 @@ start_function (FuncDeclaration *fd)
  modules not in this compilation, or thunk aliases.  */
   TemplateInstance *ti = fd->isInstantiated ();
   if (ti && ti->needsCodegen ())
-{
-  /* Warn about templates instantiated in this compilation.  */
-  if (ti == fd->parent)
-   {
- warning (OPT_Wtemplates, "%s %qs instantiated",
-  ti->kind (), ti->toPrettyChars (false));
-   }
-
-  DECL_EXTERNAL (fndecl) = 0;
-}
+DECL_EXTERNAL (fndecl) = 0;
   else
 {
   Module *md = fd->getModule ();
diff --git a/gcc/d/lang.opt b/gcc/d/lang.opt
index 7859e1583c8..51e8e5c7e00 100644
--- a/gcc/d/lang.opt
+++ b/gcc/d/lang.opt
@@ -138,10 +138,6 @@ Wspeculative
 D
 Warn from speculative compiles such as __traits(compiles).
 
-Wtemplates
-D
-; Documented in C
-
 Wunknown-pragmas
 D Var(warn_unknown_pragmas) LangEnabledBy(D, Wextra)
 ; Documented in C
-- 
2.32.0

Re: [PATCH] libgompd: add OMPD support, libgompd initialization and global ICVs functions

2022-04-03 Thread Mohamed Atef via Gcc-patches

Hi,
  I'd like to ping this patch.
Thanks

Mohamed

On Sun, Mar 20, 2022 at 11:33 AM Mohamed Atef 
wrote:

> hello,
>I know it's too much.
> we fixed the functions' names that are not part of the standard form ompd_
> * prefix to gompd_
> Thanks
>
>
> On Wed, Mar 16, 2022 at 5:48 AM Mohamed Atef 
> wrote:
>
>> Hi,
>>we found some typos in the ChangeLog and some wrong spaces (nightmare)
>> in the files.
>> So here's the best we can do.
>> and please don't be disappointed and trust us we're doing our best.
>> I hope you could review it by Sunday night.
>>
>> Thanks.
>>
>>
>> libgomp/ChangeLog
>>
>> 2022-03-15  Mohamed Atef  
>>
>> *config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>> *config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>> *config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>> *configure: Regenerate.
>> * Makefile.am (toolexeclib_LTLIBRARIES): Add libgompd.la.
>> 
>> (libgompd_la_LDFLAGS, libgompd_la_DEPENDENCIES, libgompd_la_LINK,
>> libgompd_la_SOURCES, libgompd_version_dep, libgompd_version_script,
>> libgompd.ver-sun, libgompd.ver, libgompd_version_info): New.
>> *Makefile.in: Regenerate.
>> *aclocal.m4: Regenerate.
>> *env.c: Include ompd-support.h.
>> (initialize_env): Call gompd_load.
>> *team.c: Include ompd-support.h.
>> (gomp_team_start): Call ompd_bp_parallel_begin.
>> (gomp_team_end): Call ompd_bp_parallel_end.
>> *libgomp.map: Add OMP_5.0.3 symbol versions.
>> *libgompd.map: New.
>> *omp-tools.h.in: New.
>> *ompd-types.h.in: New.
>> *ompd-support.h: New.
>> *ompd-support.c: New.
>> *ompd-helper.h: New.
>> *ompd-helper.c: New.
>> *ompd-init.c: New.
>> *ompd-icv.c: New.
>> *configure.ac (AC_CONFIG_FILES): Add omp-tools.h and ompd-types.h.
>>
>>
>> On Tue, Mar 15, 2022 at 11:32 PM Mohamed Atef 
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 15, 2022 at 11:32 PM Mohamed Atef 
>>> wrote:
>>>
 This patch added OMPD support to libgomp, api version funcitos and
 global ICVs functions.
 I hope you review it as soon as possible, to fix the problems.
 I tried as much as I could to follow GNU standards.
 We have a seminar at the college next week, so we need this to be
 reviewed.
 Thanks

 libgomp/ChangeLog

 2022-03-15  Mohamed Atef  

 *config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
 *config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
 *config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
 *configure: Regenerate.
 * Makefile.am (toolexeclib_LTLIBRARIES): Add libgompd.la
 (libgompd_la_LDFLAGS, libgompd_la_DEPENDENCIES, libgompd_la_LINK,
 libgompd_la_SOURCES, libgompd_version_dep, libgompd_version_script,
 libgompd.ver-sun, libgompd.ver, libgompd_version_info): New.
 *Makefile.in: Regenerate.
 *aclocal.m4: Regenerate.
 *env.c: Include ompd-support.h.
 (initialize_env): Call gompd_load.
 *team.c: Include ompd-support.h.
 (gomp_team_start): Call ompd_bp_parallel_begin.
 (gomp_team_end): Call ompd_bp_parallel_end.
 *libgomp.map: Add OMP_5.0.3 symbol versions.
 *libgompd.map: New.
 *omp-tools.h.in: New.
 *ompd-types.h.in: New.
 *ompd-support.h: New.
 *ompd-support.c: New.
 *ompd-helper.h: New.
 *ompd-helper.c: New.
 *ompd-init.c: New.
 *ompd-icv.c: New.
 *configure.ac (AC_CONFIG_FILES): Add omp-tools.h and ompd-types.h.

>>>

New Swedish PO file for 'gcc' (version 12.1-b20220213)

2022-04-03 Thread Translation Project Robot

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-12.1-b20220213.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] i386: Fix up ix86_expand_vector_init_general [PR105123]

2022-04-03 Thread Uros Bizjak via Gcc-patches

On Sat, Apr 2, 2022 at 11:25 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The following testcase is miscompiled on ia32.
> The problem is that at -O0 we end up with:
>   vector(4) short unsigned int _1;
>   short unsigned int u.0_3;
> ...
>   _1 = {u.0_3, u.0_3, u.0_3, u.0_3};
> statement (dead) which is wrongly expanded.
> elt is (subreg:HI (reg:SI 83 [ u.0_3 ]) 0), tmp_mode SImode,
> so after convert_mode we start with word (reg:SI 83 [ u.0_3 ]).
> The intent is to manually broadcast that value to 2 SImode parts,
> but because we pass word as target to expand_simple_binop, it will
> overwrite (reg:SI 83 [ u.0_3 ]) and we end up with 0:
>10: {r83:SI=r83:SI<<0x10;clobber flags:CC;}
>11: {r83:SI=r83:SI|r83:SI;clobber flags:CC;}
>12: {r83:SI=r83:SI<<0x10;clobber flags:CC;}
>13: {r83:SI=r83:SI|r83:SI;clobber flags:CC;}
>14: clobber r110:V4HI
>15: r110:V4HI#0=r83:SI
>16: r110:V4HI#4=r83:SI
> as the two ors do nothing and two shifts each by 16 left shift it all
> away.
> The following patch fixes that by using NULL_RTX target, so we expand it as
>10: {r110:SI=r83:SI<<0x10;clobber flags:CC;}
>11: {r111:SI=r110:SI|r83:SI;clobber flags:CC;}
>12: {r112:SI=r83:SI<<0x10;clobber flags:CC;}
>13: {r113:SI=r112:SI|r83:SI;clobber flags:CC;}
>14: clobber r114:V4HI
>15: r114:V4HI#0=r111:SI
>16: r114:V4HI#4=r113:SI
> instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Another possibility would be to pass NULL_RTX only when word == elt
> and word otherwise, where word would necessarily be a pseudo from the first
> shift after passing NULL_RTX there once or pass NULL_RTX for the shift and
> word for ior.
>
> 2022-04-02  Jakub Jelinek  
>
> PR target/105123
> * config/i386/i386-expand.cc (ix86_expand_vector_init_general): Avoid
> using word as target for expand_simple_binop when doing ASHIFT and
> IOR.
>
> * gcc.target/i386/pr105123.c: New test.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/i386-expand.cc.jj   2022-03-19 13:52:53.0 +0100
> +++ gcc/config/i386/i386-expand.cc  2022-04-01 16:51:27.253154191 +0200
> @@ -15830,9 +15830,9 @@ quarter:
>   else
> {
>   word = expand_simple_binop (tmp_mode, ASHIFT, word, shift,
> - word, 1, OPTAB_LIB_WIDEN);
> + NULL_RTX, 1, OPTAB_LIB_WIDEN);
>   word = expand_simple_binop (tmp_mode, IOR, word, elt,
> - word, 1, OPTAB_LIB_WIDEN);
> + NULL_RTX, 1, OPTAB_LIB_WIDEN);
> }
> }
>
> --- gcc/testsuite/gcc.target/i386/pr105123.c.jj 2022-04-01 16:56:44.549625810 
> +0200
> +++ gcc/testsuite/gcc.target/i386/pr105123.c2022-04-01 16:56:33.569782511 
> +0200
> @@ -0,0 +1,22 @@
> +/* PR target/105123 */
> +/* { dg-do run { target sse2_runtime } } */
> +/* { dg-options "-msse2" } */
> +/* { dg-additional-options "-mtune=i686" { target ia32 } } */
> +
> +typedef unsigned short __attribute__((__vector_size__ (4 * sizeof (unsigned 
> short V;
> +
> +V
> +foo (unsigned short u, V v)
> +{
> +  return __builtin_shuffle (u * v, v);
> +}
> +
> +int
> +main ()
> +{
> +  V x = foo (1, (V) { 0, 1, 2, 3 });
> +  for (unsigned i = 0; i < 4; i++)
> +if (x[i] != i)
> +  __builtin_abort ();
> +  return 0;
> +}
>
> Jakub
>

[committed][PR target/104987] Avoid "likely" forms of bbi[n] on iq2000.

2022-04-03 Thread Jeff Law via Gcc-patches


The iq2000 port is mis-compiling its mulsi3 libgcc2 function.

AFAICT, the iq2000 has delay slots and can use "branch-likely" forms of 
conditional branches to annul-false the slot.   There's a support 
routine that handles creation of the  likely form.  However, that 
routine is not used by the bbi[n] instructions.


If I manually add the likely extension to the bbi[b] instructions, the 
assembler complains  After a fair amount of digging it appears that the 
likely forms of bbi[n] are only supported on the IQ10 variant.


Given this is a dead processor and has been so for a while it seems 
reasonable to just disallow annul-false slots for the bbi[n] 
instructions rather than try to handle them just for the IQ10 (which we 
don't have real support for anyway).


This (of course) fixes the vrp13 regression.  But it also fixes nearly a 
thousand execution test failures in the testsuite (Yow!).


Installed on the trunk,
Jeff

diff --git a/gcc/config/iq2000/iq2000.md b/gcc/config/iq2000/iq2000.md
index fdb346f43ef..86361e27a86 100644
--- a/gcc/config/iq2000/iq2000.md
+++ b/gcc/config/iq2000/iq2000.md
@@ -165,6 +165,8 @@
 (const_string "yes")
 (const_string "no"
 
+;; Is this a bbi instruction or not
+(define_attr "bbi" "no,yes" (const_string "no"))
 
 ;; Describe a user's asm statement.
 (define_asm_attributes
@@ -183,11 +185,18 @@
(nil)
(nil)])
 
-(define_delay (eq_attr "type" "branch")
+;; GAS refuses to assemble bbi[n]l.  So for bbi instructions, do not
+;; allow them to annul-false.
+(define_delay (and (eq_attr "type" "branch") (eq_attr "bbi" "no"))
   [(and (eq_attr "dslot" "ok_in_dslot") (eq_attr "length" "4"))
(nil)
(and (eq_attr "branch_likely" "yes") (and (eq_attr "dslot" "ok_in_dslot") 
(eq_attr "length" "4")))])
 
+(define_delay (and (eq_attr "type" "branch") (eq_attr "bbi" "yes"))
+  [(and (eq_attr "dslot" "ok_in_dslot") (eq_attr "length" "4"))
+   (nil)
+   (nil)])
+
 (define_delay (eq_attr "type" "call")
   [(and (eq_attr "dslot" "ok_in_dslot") (eq_attr "length" "4"))
(nil)
@@ -1114,7 +1123,8 @@
   ""
   "bb%A2\\t%0(31-%1),%P2%P3"
   [(set_attr "length" "4")
-   (set_attr "type" "branch")])
+   (set_attr "type" "branch")
+   (set_attr "bbi" "yes")])
 
 (define_insn ""
   [(set (pc)
@@ -1128,7 +1138,8 @@
   ""
   "bb%A3\\t%0(31-%1),%P2%P3"
   [(set_attr "length" "4")
-   (set_attr "type" "branch")])
+   (set_attr "type" "branch")
+   (set_attr "bbi" "yes")])
 
 (define_insn ""
   [(set (pc)
@@ -1142,7 +1153,8 @@
   "0"
   "bb%A2\\t%0(31-%1),%P2%P3"
   [(set_attr "length" "4")
-   (set_attr "type" "branch")])
+   (set_attr "type" "branch")
+   (set_attr "bbi" "yes")])
 
 (define_insn ""
   [(set (pc)
@@ -1156,7 +1168,8 @@
   "0"
   "bb%A3\\t%0(31-%1),%P2%P3"
   [(set_attr "length" "4")
-   (set_attr "type" "branch")])
+   (set_attr "type" "branch")
+   (set_attr "bbi" "yes")])
 
 (define_insn ""
   [(set (pc)
@@ -1169,7 +1182,8 @@
   ""
   "bb%A3\\t%0(%p1),%P2%P3"
   [(set_attr "length" "4")
-   (set_attr "type" "branch")])
+   (set_attr "type" "branch")
+   (set_attr "bbi" "yes")])
 
 (define_insn ""
   [(set (pc)
@@ -1182,7 +1196,8 @@
   ""
   "bb%A2\\t%0(%p1),%P2%P3"
   [(set_attr "length" "4")
-   (set_attr "type" "branch")])
+   (set_attr "type" "branch")
+   (set_attr "bbi" "yes")])
 
 ;;
 ;;

Re: [RFC] ipa-cp: Feed results of IPA-CP into SCCVN

2022-04-03 Thread Richard Biener via Gcc-patches

On Fri, 1 Apr 2022, Martin Jambor wrote:

> Hi,
> 
> thanks for a very quick reply.
> 
> On Fri, Apr 01 2022, Richard Biener wrote:
> > On Fri, 1 Apr 2022, Martin Jambor wrote:
> >
> >> Hi,
> >> 
> >> PRs 68930 and 92497 show that when IPA-CP figures out constants in
> >> aggregate parameters or when passed by reference but the loads happen
> >> in an inlined function the information is lost.  This happens even
> >> when the inlined function itself was known to have - or even cloned to
> >> have - such constants in incoming parameters because the transform
> >> phase of IPA passes is not run on them.  See discussion in the bugs
> >> for reasons why.
> >> 
> >> Honza suggested that we can plug the results of IPA-CP analysis into
> >> value numbering, so that FRE can figure out that some loads fetch
> >> known constants.  This is what this patch attempts to do.
> >> 
> >> Although I spent quite some time reading tree-sccvn.c, it is complex
> >> enough that I am sure I am not aware of various caveats and so I would
> >> not be terribly surprised if there were some issues with my approach
> >> that I am not aware of.  Nevertheless, it seems to work well for simple
> >> cases and even passes bootstrap and testing (and LTO bootstrap) on
> >> x86_64-linux.
> >> 
> >> I have experimented a little with using this approach instead of the
> >> function walking parts of the IPA-CP transformation phase.  This would
> >> mean that the known-constants would not participate in the passes after
> >> IPA but before FRE - which are not many but there is a ccp and fwprop
> >> pass among others.  For simple testcases like
> >> gcc/testsuite/gcc.dg/ipa/ipcp-agg-*.c, it makes not assembly difference
> >> at all.
> >> 
> >> What do you think?
> >
> > Comments below
> >
> >> Martin
> >> 
> >> 
> >> gcc/ChangeLog:
> >> 
> >> 2022-03-30  Martin Jambor  
> >> 
> >>PR ipa/68930
> >>PR ipa/92497
> >>* ipa-prop.cc (ipcp_get_aggregate_const): New function.
> >>(ipcp_transform_function): Do not deallocate transformation info.
> >>* ipa-prop.h (ipcp_get_aggregate_const): Declare.
> >>* tree-ssa-sccvn.cc: Include alloc-pool.h, symbol-summary.h and
> >>ipa-prop.h.
> >>(vn_reference_lookup_2): When hitting default-def vuse, query
> >>IPA-CP transformation info for any known constants.
> >> 
> >> gcc/testsuite/ChangeLog:
> >> 
> >> 2022-03-30  Martin Jambor  
> >> 
> >>PR ipa/68930
> >>PR ipa/92497
> >>* gcc.dg/ipa/pr92497-1.c: New test.
> >>* gcc.dg/ipa/pr92497-2.c: Likewise.
> >> ---
> >>  gcc/ipa-prop.cc  | 43 
> >>  gcc/ipa-prop.h   |  2 ++
> >>  gcc/testsuite/gcc.dg/ipa/pr92497-1.c | 26 +
> >>  gcc/testsuite/gcc.dg/ipa/pr92497-2.c | 26 +
> >>  gcc/tree-ssa-sccvn.cc| 35 +-
> >>  5 files changed, 126 insertions(+), 6 deletions(-)
> >>  create mode 100644 gcc/testsuite/gcc.dg/ipa/pr92497-1.c
> >>  create mode 100644 gcc/testsuite/gcc.dg/ipa/pr92497-2.c
> >> 
> >> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
> >> index e55fe2776f2..a73a5d9ec1d 100644
> >> --- a/gcc/ipa-prop.cc
> >> +++ b/gcc/ipa-prop.cc
> >> @@ -5748,6 +5748,44 @@ ipcp_modif_dom_walker::before_dom_children 
> >> (basic_block bb)
> >>return NULL;
> >>  }
> >>  
> >> +/* If IPA-CP discovered a constant in parameter PARM at OFFSET of a given 
> >> SIZE
> >> +   - whether passed by reference or not is given by BY_REF - return that
> >> +   constant.  Otherwise return NULL_TREE.  */
> >> +
> >> +tree
> >> +ipcp_get_aggregate_const (tree parm, bool by_ref,
> >> +HOST_WIDE_INT offset, HOST_WIDE_INT size)
> >
> > I'd prefer to pass in the function decl or struct function or
> > cgraph node.
> 
> OK.
> 
> >
> >> +{
> >> +  cgraph_node *cnode = cgraph_node::get (current_function_decl);
> >> +
> >> +  ipa_agg_replacement_value *aggval = ipa_get_agg_replacements_for_node 
> >> (cnode);
> >> +  if (!aggval)
> >> +return NULL_TREE;
> >> +
> >> +  int index = 0;
> >> +  for (tree p = DECL_ARGUMENTS (current_function_decl);
> >> +   p != parm; p = DECL_CHAIN (p))
> >> +{
> >> +  index++;
> >> +  if (!p)
> >> +  return NULL_TREE;
> >> +}
> >> +
> >> +  ipa_agg_replacement_value *v;
> >> +  for (v = aggval; v; v = v->next)
> >> +if (v->index == index
> >> +  && v->offset == offset)
> >> +  break;
> >> +  if (!v
> >> +  || v->by_ref != by_ref
> >> +  || maybe_ne (tree_to_poly_int64 (TYPE_SIZE (TREE_TYPE (v->value))),
> >> + size))
> >> +return NULL_TREE;
> >
> > two linear searches here - ugh.  I wonder if we should instead
> > pre-fill a hash-map from PARM_DECL to a ipa_agg_replacement_value *
> > vector sorted by offset which we can binary search?  That could be
> > done once when starting value-numbering (not on regions).  Is
> > there any reason the data structure is as it is?
> 
> Only that it is usually a very short list.

Re: [PATCH v4] libgo: Don't use pt_regs member in mcontext_t

[committed] d: Remove Wtemplates warnings from the code generation pass

Re: [PATCH] libgompd: add OMPD support, libgompd initialization and global ICVs functions

New Swedish PO file for 'gcc' (version 12.1-b20220213)

Re: [PATCH] i386: Fix up ix86_expand_vector_init_general [PR105123]

[committed][PR target/104987] Avoid "likely" forms of bbi[n] on iq2000.

Re: [RFC] ipa-cp: Feed results of IPA-CP into SCCVN

7 matches

Site Navigation

Mail list logo

Footer information