Bug 88282 - [9 Regression] ICE in df_install_refs at gcc/df-scan.c:2379
Summary: [9 Regression] ICE in df_install_refs at gcc/df-scan.c:2379
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 9.0
: P3 normal
Target Milestone: 9.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, ra
Depends on:
Blocks:
 
Reported: 2018-11-30 13:21 UTC by Martin Liška
Modified: 2018-12-06 18:42 UTC (History)
6 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-11-30 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2018-11-30 13:21:33 UTC
Following causes ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c --param large-stack-frame=0 -Ofast -fstack-clash-protection
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c: In function ‘bf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c:22:1: internal compiler error: Segmentation fault
   22 | }
      | ^
0xa88a2f crash_signal
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:326
0x7ffff6bc310f ???
	/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7329b1 df_install_refs
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2379
0x732a94 df_install_refs
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x732a94 df_refs_add_to_chains
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x738fae df_bb_refs_record(int, bool)
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3350
0x7391bc df_scan_blocks()
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x8f127d do_reload
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5533
0x8f127d execute
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5653
Comment 1 Martin Liška 2018-11-30 13:25:29 UTC
One related testcase that fails:

$ aarch64-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c -fstack-clash-protection -O2 -fno-tree-ccp
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c: In function ‘bf’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41470.c:22:1: internal compiler error: Segmentation fault
   22 | }
      | ^
0xa88a2f crash_signal
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:326
0x7ffff6bc310f ???
	/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7329b1 df_install_refs
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2379
0x732a94 df_install_refs
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x732a94 df_refs_add_to_chains
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:2425
0x738fae df_bb_refs_record(int, bool)
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:3350
0x7391bc df_scan_blocks()
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/df-scan.c:588
0x8f127d do_reload
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5533
0x8f127d execute
	/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/ira.c:5653
Comment 2 Tamar Christina 2018-11-30 13:44:03 UTC
Confirmed, something broke in between upstreaming and now. Taking a look.
Comment 3 Tamar Christina 2018-11-30 16:42:47 UTC
This is caused by the change in r266385 for PR87718.

That causes the cost model to go completely off the rail and also changes the register classes.

Previously out costs were 0 in most cases, now we have large numbers like 65540004.

```
  r93 costs: GENERAL_REGS:0 FP_LO_REGS:10000 FP_REGS:10000 POINTER_AND_FP_REGS:10000 MEM:8000
  r92 costs: GENERAL_REGS:0 FP_LO_REGS:10000 FP_REGS:10000 POINTER_AND_FP_REGS:10000 MEM:8000
```

was before and now

```
  r93 costs: GENERAL_REGS:65540004 FP_LO_REGS:65544004 FP_REGS:65544004 POINTER_AND_FP_REGS:65544004 MEM:8000
  r92 costs: TAILCALL_ADDR_REGS:131074004 GENERAL_REGS:131074004 FP_LO_REGS:131074004 FP_REGS:131074004 POINTER_AND_FP_REGS:131074004 MEM:8000
```

The reason this crashes with stack clash enabled is because the alloca code emits a probe at SP.

The costing now makes it think it has to spill the hard register

      Creating newreg=98 from oldreg=92, assigning class GENERAL_REGS to r98
   16: sp:DI=r98:DI
      REG_DEAD r92:DI
      REG_ARGS_SIZE 0
    Inserting insn reload before:
   27: r98:DI=r92:DI


 it can't do it so it crashes in reload.
Comment 4 Vladimir Makarov 2018-11-30 19:03:28 UTC
(In reply to Tamar Christina from comment #3)
> This is caused by the change in r266385 for PR87718.
> 
> That causes the cost model to go completely off the rail and also changes
> the register classes.
> 

  Sorry for this. It was a very sensitive code change and I think it will take some time until the code stabilize.  But I believe that what patch for PR87718 solves is the right direction for RA.

> Previously out costs were 0 in most cases, now we have large numbers like
> 65540004.
> 
> ```

  I'll investigate this too. The biggest problem with RA cost calculations is that machine-dependent code for register move cost is not defined correctly for all combinations of mode, regclass, regclass.  Unfortunately, the documentation says nothing about it.  RA tries to solve this in some ways but not always successfully. 

  In the current case the combination is DImode, SP_REG, GENERAL_REGS.

  I'll see what can I do in RA.  I have an idea. If it works the patch will be ready on the next week.
Comment 5 Uroš Bizjak 2018-12-02 08:26:15 UTC
(In reply to Tamar Christina from comment #3)
> This is caused by the change in r266385 for PR87718.
> 
> That causes the cost model to go completely off the rail and also changes
> the register classes.

FTR, there are also some new inconsistencies w.r.t cost model on x86, as reported here [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02419.html
Comment 6 Tamar Christina 2018-12-03 10:05:27 UTC
>   I'll see what can I do in RA.  I have an idea. If it works the patch will be ready on the next week.

Thanks Vladimir!
Comment 7 Vladimir Makarov 2018-12-04 15:11:19 UTC
Author: vmakarov
Date: Tue Dec  4 15:10:46 2018
New Revision: 266784

URL: https://gcc.gnu.org/viewcvs?rev=266784&root=gcc&view=rev
Log:
2018-12-04  Vladimir Makarov  <vmakarov@redhat.com>

	PR target/88282
	* ira-costs.c (exec): Try bigger class to use smaller register
	move cost.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-costs.c
Comment 8 Jeffrey A. Law 2018-12-04 15:24:05 UTC
Fixed by Vlad's patch on the trunk.
Comment 9 Vladimir Makarov 2018-12-06 18:42:18 UTC
Author: vmakarov
Date: Thu Dec  6 18:41:46 2018
New Revision: 266862

URL: https://gcc.gnu.org/viewcvs?rev=266862&root=gcc&view=rev
Log:
2018-12-06  Vladimir Makarov  <vmakarov@redhat.com>

	PR target/88282
	* ira.c (ira_init_register_move_cost): Use info from
	hard_regno_mode_ok instead of contains_reg_of_mode.
	* ira-costs.c (contains_reg_of_mode): Don't use cost from bigger
	hard register class for some fixed hard registers.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-costs.c
    trunk/gcc/ira.c