If we are going to write handler data (that is written as variable length data following after the unwind info in .xdata), we need to emit the handler data immediately, but for cases where no such info is going to be written, skip emitting it right away. (Unwind info for all remaining functions that hasn't gotten it emitted directly is emitted at the end.)
This also matches GCC's assembly output, which doesn't output .seh_handlerdata unless it actually is needed.
For ARM64, the unwind info can be packed into the runtime function entry itself (leaving no data in the .xdata section at all), but that can only be done if there's no follow-on data in the .xdata section. If emission of the unwind info is triggered via EmitWinEHHandlerData (or the .seh_handlerdata directive), which implicitly switches to the .xdata section, there's a chance of the caller wanting to pass further data there, so the packed format can't be used in that case.
This turned out to be the reason why D87371 had no effect at all, as it forced .seh_handlerdata at the end of all functions. With this patch in place, D87371 has got a small effect (but very few functions in practice end up matching).
When I first saw this variable name I thought it was some kind of offset. But now I see it's really an index into WinFrameInfos.
Maybe CurrentProcWinFrameInfoIndex would be a better name? And should it be initialized to -1 or some other invalid value rather than 0, since I assume it should always be set here before it's used?