> > Unfortunately the proper fix did not make it to the mainlie (it probably > > will > > next stage1). Building kernel is however important. Can you please fill it > > in > > and mark it as a regression? I think I will implement a hack and track > > everything > > that refers user named labels and force it to partition 0. Ugly but probably > > best we can do at the moment. > > > > It would help to track it as a regression. > > Sorry, actually I don't think it's a regression. The kernel moved > the BPF interpreter to a new file, so my old workaround (disabling LTO > for the file) broke. But it has been broken in gcc for quite some > time (and if it wasn't it probably was just by partitioning accident) > > Would be still good to fix it though, if not too intrusive.
Yes, i think there is resonaly constrained fix. My original fix was to add new type of symbol table entry (label) and new type of reference (this definition is contained in definition of another symbol) and make all symtab code to work with it + teach partitioning to never put contained deifnitions to different partition. Because we prevent inlining functions taking labels, I think situation is however a lot easier. We can just track what variables reffer to a local label. Those must be local statics, so we have to containment info available via ABSTRACT_ORIGIN and we can make partitioning to group things accordingly. I will try to get this implemented - it only needs new flag on varpool node + change in the partitioner (that already know how to handle similar cases for inline clones) Honza
