Add isDebug flag to SectionBase to avoid multiplue string
comparisions by isDebugSection() function.
Details
- Reviewers
ruiu grimar MaskRay • espindola
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Most links don't use --strip-debug or --strip-all, so isDebugSection in LinkerDriver::link is rarely called.
Most links don't specify -r or --emit-relocs, so InputSection::copyRelocations is not called. In addition, isDebugInfo inside the function is called by edge cases which we have to suppress warnings for practical reasons, the cases are even fewer.
I am hesitant to accept this patch, unless you can make further justification.
Most links don't use --strip-debug or --strip-all, so isDebugSection in LinkerDriver::link is rarely called.
Most links don't specify -r or --emit-relocs, so InputSection::copyRelocations is not called. In addition, isDebugInfo inside the function is called by edge cases which we have to suppress warnings for practical reasons, the cases are even fewer.
I am hesitant to accept this patch, unless you can make further justification.
I intend to use it for D74169(where checking for debug section is used more frequently). If not for D74169 then it would be suitable for any future checking of debug section(support of .debug_names?). This change costs nothing. It does not increase the size of SectionBase. Thus it seems to me it would be useful to do this patch even if it does not show noticeable performance impact right now.
I added a comment about this previously, I think it was not answered?
https://reviews.llvm.org/D74169#inline-709439
My assumption was that it is a premature unproved optimization (while you did not show the numbers, e.g. link time with/without it).
(Honestly I would be surprised to see a speed-up after doing this. At least while you have cases with 889% link time, my feeling is that something else is slow, but not this).
This change costs nothing.
This part is a bit wrong atm. It costs us:
- A bit in SectionBase, which might be needed in the future.
- It causes code readers to think that this is a useful optimization, though it is unproved yet. (General rule of LLD is do no work that can be avoided. It helps it to be that fast).
- More code for perhaps no reason.
I added a comment about this previously, I think it was not answered?
https://reviews.llvm.org/D74169#inline-709439
My assumption was that it is a premature unproved optimization (while you did not show the numbers, e.g. link time with/without it).
(Honestly I would be surprised to see a speed-up after doing this. At least while you have cases with 889% link time, my feeling is that something else is slow, but not this).
you are right. It does not have noticeable effect. would close that review.