[lld] [lld] More info for aarch64 ldr/str misaligning error (PR #135004)
Martin Storsjö via llvm-commits
llvm-commits at lists.llvm.org
Fri Apr 11 06:57:26 PDT 2025
mstorsjo wrote:
> I think having good diagnostics is important for the user experience. MSVC isn't particularly good at that and neither is LLD, although a bit better than MSVC.
Definitely. Although this is a quite unusual/internal diagnostic; I'm not really sure how easy it is to even hit this one with just regular user code, unless the toolchain is faulty/broken. But nevertheless, for whoever is working on the potentially faulty toolchain it's not easy to pinpoint the issue unless we give more hints, so I'm all for improving the diagnostics here.
> In regards to performance, I wonder if we could extend `Twine` to incorporate `llvm::function_ref`. I found myself often in such occasions where we're torn between the informative aspect of the message, and not doing too much processing upfront for a error message that might never occur. If we shovel a lambda in the `Twine`, messages will only be prepared when needed, with no measurable impact if they don't occur.
That's certainly a good option too. I wonder how much lowlevel overhead there is in such a lambda; probably not much at all? It mostly needs to make sure that any referenced/captured variable is stored in its canonical location in the stack frame of the caller, right?
Another alternative would be to just pass in more of the variables we have in the callers, into the functions, allowing the functions themselves to format everything they want/need once they want to (possibly encapsulated in a helper function). Although I'm not sure if this any better/worse than just passing in a single lambda either. And it forces passing in a lot of parameters we don't usually need.
The tricky part here is actually measuring the performance impact; I did try out this patch (on linking a large-ish binary like clang.exe - that's probably the biggest one I regularly build) and I'm not sure I see any measurable difference with this patch as-is, at least not anything really big. So it's hard to measure and figure out whether it's better to gather everything and just format one single `Twine` like this does, ahead of time, compared to the cost of setting up and passing in a lambda.
https://github.com/llvm/llvm-project/pull/135004
More information about the llvm-commits
mailing list