[PATCH] D140478: [RISCV] For Dwarf v5, emit indices into .debug_addr for range list entries

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D140478#4012779 <https://reviews.llvm.org/D140478#4012779>, @RamNalamothu wrote:

> In D140478#4011085 <https://reviews.llvm.org/D140478#4011085>, @dblaikie wrote:
>
>> Is there any mechanism that tests whether a given range bounded by two labels may be subject to linker relaxation? It'd be nice to have that abstraction and use it here (& in some other places in DWARF emission) rather than hardcoding one particular architecture.
>
> Unless the relaxations are performed during the assembling, this may not be possible before linking because we will not know which set of labels have instruction sequence(s) that the linker actually might be able to relax after finishing the section layout.
> So, depending on whether linker relaxations are enabled, I think we can only either emit relocatable symbols for all the range labels or never.

Yeah, such a query wouldn't have to be precise, only conservatively correct - so if you can't be sure a given range won't be relaxed, then the query would say that it might be & DWARF would be emitted that'd be resilient to such relaxation.

>> The other place this would be needed is in the low/high_pc computation, since currently, even in DWARFv4, the high_pc is encoded as a delta from low_pc, not as a separate relocatable label, so that'd need the same checking.
>
> I have introduced a new MCAsmInfo API to check if we need relocatable symbol references in dwarf entries based on whether the linker relaxations are enabled.



In D140478#4011149 <https://reviews.llvm.org/D140478#4011149>, @tmsriram wrote:

> In D140478#4011085 <https://reviews.llvm.org/D140478#4011085>, @dblaikie wrote:
>
>> Is there any mechanism that tests whether a given range bounded by two labels may be subject to linker relaxation? It'd be nice to have that abstraction and use it here (& in some other places in DWARF emission) rather than hardcoding one particular architecture.
>>
>> The other place this would be needed is in the low/high_pc computation, since currently, even in DWARFv4, the high_pc is encoded as a delta from low_pc, not as a separate relocatable label, so that'd need the same checking.
>>
>> And I was thinking that PROPELLER needed/was considering doing some linker relaxation too, so could benefit from such an abstraction/hook/check - but maybe they didn't end up needing/using linker relaxation? (@tmsriram - did PROPELLER ever end up needing/using linker relaxation? is that still something under consideration?)
>
> Propeller needs linker relaxation for branch instructions.  Making it a shorter branch when the offset can fit in one byte and flipping branches, from like je to jne to convert and remove a subsequent fallthrough.
>
> I remember dealing with issues regarding low_pc, high_pc. I think you reviewed these patches,  I forget the details now and can take another look to see how this can help.

Hmm, yeah, I'm confused - because I'd expect the code for ranges to have to handle this but judging by the code being added in this patch, the code isn't already there that I'd expect to be there for linker relaxation in PROPELLER.

Could you point me to the reviews and/or a simple-ish example that would reproduce the relaxation behavior for PROPELLER so I can see how the DWARF is emitted/works uot?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140478/new/

https://reviews.llvm.org/D140478