[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Aldy Hernandez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Aldy Hernandez --- If we care about this on non MIPS16 targets, we can open a new PR and reference this one, perhaps with a less target specific title :).
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #14 from Jeffrey A. Law --- I suspect we could likely show a similar codesize and performance regression on other targets. ppc & arm come to mind. aarch64 as well, but it wouldn't be a regression there since it didn't exist when this was first reported. mips16? Na, I don't care too much about that :-)
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #13 from Aldy Hernandez --- Do we care though? Does this bug pose a big enough problem on non MIPS16 that we would like addressed? Just curious On Sun, Feb 4, 2018 at 10:50 AM, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 > > --- Comment #12 from Jeffrey A. Law --- > One more tidbit here. I noted that we got "reasonably" close to having enough > state in the combiner to attack this in c#7. The problem is there's a REG > object that we really need to be a CONST_INT. > > It turns out that we're failing to substitute the value from a REG_EQUAL note > as combine builds up that hunk of RTL. So if we were to substitute in the > REG_EQUAL, then we'd have a fighting chance to address this in the combiner. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 --- Comment #12 from Jeffrey A. Law --- One more tidbit here. I noted that we got "reasonably" close to having enough state in the combiner to attack this in c#7. The problem is there's a REG object that we really need to be a CONST_INT. It turns out that we're failing to substitute the value from a REG_EQUAL note as combine builds up that hunk of RTL. So if we were to substitute in the REG_EQUAL, then we'd have a fighting chance to address this in the combiner.
[Bug rtl-optimization/59393] [6/7/8 regression] mips16/7/8 code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393 Aldy Hernandez changed: What|Removed |Added Status|NEW |WAITING CC||aldyh at gcc dot gnu.org --- Comment #11 from Aldy Hernandez --- I have chatted with Sandra (the original reporter) who has confirmed that the size for the original testcase on current mainline is 2296 bytes on MIPS16. This is better than the reported regression, but still not as good as 4.7. The reporter is OK with closing the PR since they no longer care about MIPS16. However, as far as I understand, this may affect other architectures. Is this at all on our radar to fix, or can we either (a) close as WONTFIX (b) move the target milestone to GCC 9? Thanks.
