[llvm-commits] [llvm] r132451 - in /llvm/trunk: include/llvm/MC/MCInstPrinter.h lib/MC/MCAsmStreamer.cpp lib/MC/MCInstPrinter.cpp lib/Target/ARM/InstPrinter/ARMInstPrinter.cpp lib/Target/ARM/InstPrinter/ARMInstPrinter.h lib/Target/PowerPC/InstPrinter/PPCInstPrinter.cpp lib/Target/PowerPC/InstPrinter/PPCInstPrinter.h lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp lib/Target/X86/InstPrinter/X86ATTInstPrinter.h lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp lib/Target/X86/InstPrinter/X86IntelInstPrinter.h

Jim Grosbach grosbach at apple.com
Thu Jun 2 11:17:40 PDT 2011

On Jun 2, 2011, at 11:09 AM, Rafael Avila de Espindola wrote:

>> That does raise another question, though. In looking at this, I
>> noticed that in an old patch (121471), the TargetAsmInfo class was
>> introduced and it contains a pointer to a TargetRegisterInfo. That's
>> a layering problem, as it forces anything MC based to link in the
>> entire codegen backend (TargetRegisterInfo is part of the
>> MachineInstr layer). Can we find a better way to do this? Some
>> tablegenerated helper functions, perhaps?
> There was already a dependency, so TargetRegisterInfo looked like the smaller hack at the time.
Yeah, there's unfortunately some nastiness that needs the targetmachine. The plan at this point is to work towards getting rid of that, but until then do our best not to add any additional linkages that make that process harder.

> The reverse mapping is already tablegenerated and could be moved to MC.
> Unfortunately, there is still information that is used in MC and Codegen because of the old JIT. We could move it and break the MC -> CodeGen dependency, but the idea of changing soon to be dead code is not too attractive.
> Another option is just duplicating some info in MC and CodeGen for now.

As long as the MC stuff has direct access without talking to the codegen layer, I'm not too concerned about the specifics, really. There's already some examples of duplicated helper functions  (getARMRegisterNumbering() is the example that jumps immediately to mind, and is one that could be replaced by auto-generated bits).


More information about the llvm-commits mailing list