[PATCH 0/2] rh2059646 - compilation of prusa-slicer hangs

[PATCH 0/2] rh2059646 - compilation of prusa-slicer hangs

[Alan Modra]

rh2059646-reduced.s is a 10M source for one function extracted from
the 386M source attached to
https://bugzilla.redhat.com/show_bug.cgi?id=2059646

Assembly even of the reduced file takes a long time, and the default
stack of 8M is not enough to handle recursion of resolve_symbol_value
starting from case rs_leb128 in gas/write.c:relax_segment.  There is
one extremely long chain of expressions evaluating view numbers,
123582 deep if I calculated correctly.  The source has that many .loc
directives in a row without intervening assembly instructions!

$ time ~/build/gas-virgin/all/gas/as-new -o xxx.o rh2059646-reduced.s
Segmentation fault (core dumped)

real	4m10.792s
user	4m9.810s
sys	0m0.080s

$ ulimit -s 65536
$ time ~/build/gas-virgin/all/gas/as-new -o xxx.o rh2059646-reduced.s

real	37m38.141s
user	37m37.930s
sys	0m0.052s

After applying the following patches:

$ time ~/build/gas/all/gas/as-new -o yyy.o rh2059646-reduced.s

real	0m0.350s
user	0m0.330s
sys	0m0.020s


Alan Modra (2):
  Reduce duplicated symbol_clone_if_forward_ref work
  Constant fold view increment expressions

 gas/dwarf2dbg.c |  1 +
 gas/symbols.c   | 11 ++++++++---
 2 files changed, 9 insertions(+), 3 deletions(-)

[PATCH 1/2] Reduce duplicated symbol_clone_if_forward_ref work

[Alan Modra]

	* symbol.c (struct symbol_flags): Add forward_resolved.
	(symbol_entry_find): Update needle initialisation.
	(symbol_clone_if_forward_ref): Do no work when forward_resolved
	is already set.  Set forward_resolved.

diff --git a/gas/symbols.c b/gas/symbols.c
index 2a0ee7783c0..b35c6d25aca 100644
--- a/gas/symbols.c
+++ b/gas/symbols.c
@@ -61,8 +61,10 @@ struct symbol_flags
   /* Whether the symbol can be re-defined.  */
   unsigned int volatil : 1;
 
-  /* Whether the symbol is a forward reference.  */
+  /* Whether the symbol is a forward reference, and whether such has
+     been determined.  */
   unsigned int forward_ref : 1;
+  unsigned int forward_resolved : 1;
 
   /* This is set if the symbol is defined in an MRI common section.
      We handle such sections as single common symbols, so symbols
@@ -202,7 +204,7 @@ static void *
 symbol_entry_find (htab_t table, const char *name)
 {
   hashval_t hash = htab_hash_string (name);
-  symbol_entry_t needle = { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+  symbol_entry_t needle = { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
 			      hash, name, 0, 0, 0 } };
   return htab_find_with_hash (table, &needle, hash);
 }
@@ -777,7 +779,9 @@ symbol_clone (symbolS *orgsymP, int replace)
 symbolS *
 symbol_clone_if_forward_ref (symbolS *symbolP, int is_forward)
 {
-  if (symbolP && !symbolP->flags.local_symbol)
+  if (symbolP
+      && !symbolP->flags.local_symbol
+      && !symbolP->flags.forward_resolved)
     {
       symbolS *orig_add_symbol = symbolP->x->value.X_add_symbol;
       symbolS *orig_op_symbol = symbolP->x->value.X_op_symbol;
@@ -830,6 +834,7 @@ symbol_clone_if_forward_ref (symbolS *symbolP, int is_forward)
 
       symbolP->x->value.X_add_symbol = add_symbol;
       symbolP->x->value.X_op_symbol = op_symbol;
+      symbolP->flags.forward_resolved = 1;
     }
 
   return symbolP;

[PATCH 2/2] Constant fold view increment expressions

[Alan Modra]

The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3.

	* dwarf2dbg.c (set_or_check_view): Remove useless assertion.
	Resolve multiple view increments.
	* testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.

diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
index 7269c4cdf87..ba97b5f0126 100644
--- a/gas/dwarf2dbg.c
+++ b/gas/dwarf2dbg.c
@@ -402,18 +402,27 @@ set_or_check_view (struct line_entry *e, struct line_entry *p,
   if (viewx.X_op != O_constant || viewx.X_add_number)
     {
       expressionS incv;
+      expressionS *p_view;
 
       if (!p->loc.u.view)
-	{
-	  p->loc.u.view = symbol_temp_make ();
-	  gas_assert (!S_IS_DEFINED (p->loc.u.view));
-	}
+	p->loc.u.view = symbol_temp_make ();
 
       memset (&incv, 0, sizeof (incv));
       incv.X_unsigned = 1;
       incv.X_op = O_symbol;
       incv.X_add_symbol = p->loc.u.view;
       incv.X_add_number = 1;
+      p_view = symbol_get_value_expression (p->loc.u.view);
+      if (p_view->X_op == O_constant || p_view->X_op == O_symbol)
+	{
+	  /* If we can, constant fold increments so that a chain of
+	     expressions v + 1 + 1 ... + 1 is not created.
+	     resolve_expression isn't ideal for this purpose.  The
+	     base v might not be resolvable until later.  */
+	  incv.X_op = p_view->X_op;
+	  incv.X_add_symbol = p_view->X_add_symbol;
+	  incv.X_add_number = p_view->X_add_number + 1;
+	}
 
       if (viewx.X_op == O_constant)
 	{
diff --git a/gas/testsuite/gas/elf/dwarf2-18.d b/gas/testsuite/gas/elf/dwarf2-18.d
index db7a4f9f20b..fbaebaa9019 100644
--- a/gas/testsuite/gas/elf/dwarf2-18.d
+++ b/gas/testsuite/gas/elf/dwarf2-18.d
@@ -2,9 +2,8 @@
 #readelf: -x.rodata -wL
 #name: DWARF2 18
 # The am33 cr16 crx ft32 mn10 msp430 nds32 and rl78 targets do not evaluate the subtraction of symbols at assembly time.
-# The mep targets turns some view computations into complex relocations.
 # The riscv targets do not support the subtraction of symbols.
-#xfail: am3*-* cr16-* crx-* ft32*-* mep-* mn10*-* msp430-* nds32*-* riscv*-* rl78-*
+#xfail: am3*-* cr16-* crx-* ft32*-* mn10*-* msp430-* nds32*-* riscv*-* rl78-*
 
 Hex dump of section '\.rodata':
   0x00000000 0100 *.*

Fix for bug 28924

[Viorel Preoteasa]

Hello,

We have a fix for bug 28924.

https://sourceware.org/bugzilla/show_bug.cgi?id=28924

The fix is very simple and involves very small changes (2 lines). How 
can we have this fix applied? If I send the changes could someone apply 
the fix?

I could also try to produce a test which does not depend on gcc that 
reveals the problem. The dependency on gcc make the test unreliable.

Best regards,

Viorel Preoteasa

Re: Fix for bug 28924

[Nick Clifton]

Hi Viorel,

> We have a fix for bug 28924.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=28924
> 
> The fix is very simple and involves very small changes (2 lines). How can we have this fix applied? If I send the changes could someone apply the fix?

Please submit the patch to the binutils mailing list, so that it can be reviewed.

It would also help if you can add a link to the email to PR 28924, once the email
appears in the binutils mailing list archive.


> I could also try to produce a test which does not depend on gcc that reveals the problem. The dependency on gcc make the test unreliable.

That would be appreciated.  A patch that includes a test is always better than
one that does not.

Cheers
   Nick

Re: Fix for bug 28924

[Viorel Preoteasa]

Hi Nick,

I noticed that you answered the bug 28924. I have now added a file that 
can be used to reproduce the problem, and I added also the information 
required to fix the problem.

Viorel

On 3/9/2022 1:42 PM, Nick Clifton wrote:
> Hi Viorel,
>
>> We have a fix for bug 28924.
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=28924
>>
>> The fix is very simple and involves very small changes (2 lines). How 
>> can we have this fix applied? If I send the changes could someone 
>> apply the fix?
>
> Please submit the patch to the binutils mailing list, so that it can 
> be reviewed.
>
> It would also help if you can add a link to the email to PR 28924, 
> once the email
> appears in the binutils mailing list archive.
>
>
>> I could also try to produce a test which does not depend on gcc that 
>> reveals the problem. The dependency on gcc make the test unreliable.
>
> That would be appreciated.  A patch that includes a test is always 
> better than
> one that does not.
>
> Cheers
>   Nick
>