|Summary:||partitioner partitions static arrays with label references|
|Product:||gcc||Reporter:||Andi Kleen <andi-gcc>|
|Component:||lto||Assignee:||Not yet assigned to anyone <unassigned>|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2021-12-24 00:00:00|
Description Andi Kleen 2017-12-11 16:38:07 UTC
Comment 1 Andi Kleen 2017-12-11 16:40:55 UTC
Comment 2 Martin Liška 2017-12-18 13:00:25 UTC
Confirmed, let me take a look.
Comment 3 Martin Liška 2018-01-03 13:57:21 UTC
> I thought there was already a bug for this, but can't find it right now. > You maybe confused that with the issue abould global asm statements that go to a random partition and cause issues with LTO? In this case, it's not work for IPA comdat, because this is pure C code. cgraph situation: f/2 (f) @0x7ff1b1d73000 Type: function definition analyzed Visibility: externally_visible prevailing_def_ironly public References: data.1957/4 (read)x/0 (read)x/0 (write)y/1 (read)y/1 (write)x/0 (read)x/0 (write)y/1 (read)y/1 (write) Referring: Read from file: /tmp/ccRhP0dr.o First run: 0 Function flags: count: 1073741826 (estimated locally) Called by: main/3 (1073741825 (estimated locally),1.00 per call) Calls: data.1957/4 (data) @0x7ff1b1d71200 Type: variable definition analyzed Visibility: prevailing_def_ironly References: Referring: f/2 (read) Read from file: /tmp/ccRhP0dr.o Availability: not-ready Varpool flags: initialized I suggest to extend LTO partitioning to find all functions with a computed goto. And for these, put simply all static variables into a same partition. I expect computed goto as quite rare feature. More fine approach would be to investigate DECL_INITIAL for LABELs. Honza what do you think?
Comment 4 Martin Liška 2018-02-16 14:49:50 UTC
So Honza is suggesting to introduce IPA_REF_LABEL_ADDR and then do proper LTO partitioning. Let me do this for GCC 9.
Comment 5 Martin Liška 2018-10-10 12:03:29 UTC
I consider label refs not so common for LTO, thus deferring for now...
Comment 6 Andi Kleen 2018-10-10 16:16:09 UTC
This breaks Linux kernel LTO builds. I currently have a workaround (disabling LTO for that file), but I don't think your "is not common" argument is valid.
Comment 7 Martin Liška 2018-10-11 11:59:35 UTC
(In reply to Andi Kleen from comment #6) > This breaks Linux kernel LTO builds. I currently have a workaround > (disabling LTO for that file), but I don't think your "is not common" > argument is valid. Well, I guess pushing LTO into Linux kernel would be difficult task to achieve. Can you please point me to a source file where it's used? Note that I did experiments with openSUSE distribution and I haven't seen it for any core package when using -flto.
Comment 8 Jan Hubicka 2018-10-11 12:48:51 UTC
> > This breaks Linux kernel LTO builds. I currently have a workaround > > (disabling LTO for that file), but I don't think your "is not common" > > argument is valid. > > Well, I guess pushing LTO into Linux kernel would be difficult task to achieve. > Can you please point me to a source file where it's used? > Note that I did experiments with openSUSE distribution and I haven't seen it > for any core package when using -flto. In most cases we get lucky as we home variables into same partition as function, so the issue does not trigger that often. Still will try to find time to fix it this stage1. Honza
Comment 9 andi 2018-10-11 17:32:35 UTC
It's in kernel/bpf/core.c It won't happen every time on a build unless you force 1on1 partitioning.
Comment 10 Andrew Pinski 2021-12-24 11:57:10 UTC
Dup of bug 50676. *** This bug has been marked as a duplicate of bug 50676 ***