https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> --- Pardom for taking so long to chime in. I suspect the source of the problem is the lack of internal view reset computations. Without that, the assembler gets an uninterrupted chain of symbolic views, in which each view is computed based on the view before it and the offset between the addresses in which they were issued. Depending on the order in which the assembler attempts to resolve each view to a constant, it could get expensive. It was never meant for this kind of use: it was expected that most views would be zero-asserts, so this wouldn't arise. This also points at the solution: to define the target hook that tells the compiler which insns are reset points, so that the compiler can use the assembler .loc view support in the way it was designed to be used. If insn lengths, as computed by gcc, are enough to determine whether or not an insn takes up any code space, defining the reset_location_view target hook to just return zero will do; otherwise, if more elaborate decisions are needed, it may return 1 or -1 to override the length-based computation.
