[PATCH] Allowing MC backends to decide relaxation based on fixup resolution

Jim Grosbach grosbach at apple.com
Fri Mar 20 11:49:49 PDT 2015


Ah, right. I see what you're saying now.

So, the concern I have here is that because some targets have more complicated relaxation decisions to make, all targets need to have additional logic inserted into their backend hooks. It's simple logic "if (!Resolved) return true;" but if it's not there, things will go badly wrong. That is, this approach complicates the interface for every target in order to support a subset. That's suboptimal.

Instead, have you considered making the logic in relaxInstruction() smarter? It's unconditional right now, but what if that were changed so that AsmBackend::relaxInstruction() so that it can cleanly choose to do nothing. What it's really for is to say to the backend, "do whatever you need to do here for an instruction that we can't statically determine the optimal size for." If we do that, everything for current targets stays the same (possibly modulo adding a constant return value to their relaxInstruction() implementations depending on implementation details). The complexity for handling more options will go in the target independent code in MCAssembler::relaxInstruction() and in the targets themselves that need the additional logic. MCAssembler::relaxInstruction()'s caller MCAssembler::layoutSectionOnce() is already set up to handle things correctly if relaxInstruction() doesn't actually make any changes.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8217

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list