On Tue, Nov 5, 2024 at 6:08 PM Andi Kleen <a...@firstfloor.org> wrote: > > On Tue, Nov 05, 2024 at 09:47:17AM +0100, Richard Biener wrote: > > On Tue, Nov 5, 2024 at 2:02 AM Jason Merrill <ja...@redhat.com> wrote: > > > > > > On 10/31/24 4:40 PM, Andi Kleen wrote: > > > > From: Andi Kleen <a...@gcc.gnu.org> > > > > > > > > autofdo looks up inline stacks and tries to match them with the profile > > > > data using their symbol name. Make sure all decls that can be in a > > > > inline stack > > > > have a valid assembler name. > > > > > > > > This fixes a bootstrap problem with autoprofiledbootstrap and LTO. > > > > > > OK in a week if no other comments. > > > > Hmm, but DECL_ABSTRACT_P should be only set on entities that generate no > > code. > > > > How does autofdo look them up? Are you sure it's the abstract decl > > autofdo wants > > to lookup? Or is autofdo processing not serializing the compilation and > > thus it > > affects code generation on parts that have not been processed yet? > > > autofdo tries to match inlines to an inline stack derived from dwarf. > So if something appears in dwarf it has to be in its stack. For the > test case the abstract entity is in the dwarf stack. > > For the inside gcc lookup it walks the BLOCK_SUPERCONTEXT links > and looks at BLOCK_ABSTRACT_ORIGIN and ignores everything that has unknown > location > > Maybe there could be some filtering there, but it would need to be on > both sides, which would be a version break for the file format.
Ah, OK - I wasn't aware it uses/requires debug info. It's still a bit odd that only the abstract decl has the correct symbol name. If it's abstract shouldn't it have the same symbol name as an actual entry? Maybe the symbol name noted in the debug info is wrong? I think the only DECL_ABSTRACT_P decls we have are from C++ CTOR/DTOR stuff. In any case, I withdraw my objection. Thanks for explaining, Richard. > -Andi >
