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. -Andi
