Dup of #29571 ?

Yes, this is a dup of #29571. I had hoped CL 170445 would fix instances like this, but it looks like it hasn't.

The reason CL 170445 didn't work is that these nops really are needed for correct tracebacks.
A binary.LittleEndian.Uint32 call reduces to a single instruction, which has a line number inside the inlined Uint32 function. If we took a profiling sample at that instruction, the nop is there to represent the location of the call in the parent function (blockGeneric, in this case). There aren't any other instructions in the parent frame which could be used as a substitute.

We could give the single instruction the line number of the parent, which would then obviate the need for the nop. I'm not sure what a principled method for making that happen would be, though. At the time of inlining, it isn't obvious that the inlined body will reduce to a single instruction (and it won't, on architectures that can't do unaligned loads).

In DWARF a single instruction can represent a stack of inlined function calls. So a profiling sample at that instruction would carry both the location in binary.LittleEndian.Uint32 and in the caller. Not sure if that makes any sense in the Go context.

The Go inline markers can only represent a single frame.
That's not the problem here, though. Each of the inline marks represents a different call site.

I'm sure I'm misunderstanding this, but if each inline mark represents a different call site, then doesn't that imply that the inlined call was completely eliminated? I don't see a reason to keep an instruction around to represent a call that was optimized away.

The body of the inlined call compiles to a single instruction. That instruction has a pc/line of the body of the inlined call. That instruction has a "parent" pointer to a nop instruction, which has a pc/line of the call site.

It seems to me that if we could attach a call stack to an instruction, then the single instruction of the inlined call would describe both the location of the inlined function and the location of the call to the inlined function, and the separate nop instruction would not be required.

True, one way to fix this would be to allow multiple locations to be attached to a single instruction. That's currently not possible.
For profiling maybe we could just do it in DWARF? For things like runtime.Callers we'd need to do it ourselves in the pcln tables.