[LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter
Carter, Jack
jcarter at mips.com
Thu Dec 6 14:49:06 PST 2012
Older targets like Mips had/have assemblers and ABIs that carry a lot of baggage.
The small bit of baggage that is giving me fits is that MipsELFObjectWriter needs to know the relocation model (static,pic,cpic), whether we are using xgot (-mgot), which abi (old,new), which architecture (32r[123],64[123]), which if any coprocessor or extention instructions are used (mips16,micromips,etc.).
I shouldn't have to muck with base classes to handle esoteric target specific issues such as these.
<target>ELFObjectWriteris used for direct object output whether directly from the codegen or from the llvm-mc assembler.
The grand idea was to use MipsSubtarget because it has almost everything I need, but the big glitch is that is only used by llc and when used directly by llvm-mc, we only get the base class MCSubtargetInfo.
AsmPrinter has access to the codegen variation (<target>Subtarget) and thus doesn't have this issue.
Is the answer for every create<target>MCSubtargetInfo() call to mimic <target>TargetMachine and create a <target>Subtarget? This would give a target a common class object to work from. The mechanism for filling the information doesn't need to be the same, but the subclass does.
This seems a bit heavy handed. I am also looking at Features to see if that could be abused into passing the information. The Features string is stored in the MCSubtarget base class.
I believe a clean solution to this could lead to much simpler parameter lists for creating other MC class objects as well, but currently I just want my e_header hurt to go away.
Feedback please
Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121206/ea48b97f/attachment.html>
More information about the llvm-dev
mailing list