<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 16, 2010, at 4:01 PM, Jason Kim wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>+llvmdev<br>-llvmcommits<br><br>On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br><blockquote type="cite">Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the LDRi12 instruction and how it registers a fixup for the addrmode_imm12 operand when it needs one.<br></blockquote><br>Hi Jim,. follow up question for ya:<br><br>The current movt/movw pair (as defined in ARMInstrInfo.td) does not<br>use EncoderMethod string to declare a special case handler.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>There's two parts to how this works. First, is the handling of the movt/movw pair for instruction selection, and then the handling of the upper/lower operand flags for those instructions.</div><div><br></div><div><div>MOVi32imm is expanded as a pseudo instruction in ARMExpandPseudos pass, and any other patterns that do similar things should also be expanded there. For a few special cases where we need the post-RA scheduler to handle the instruction sequences as an atomic unit (PICLDR, PICADD, the eh.sjlj.setjmp/longjmp patterns, for example), we expand them even later, during MC lowering in ARMAsmPrinter.cpp. As a result, the movt and movw instructions should make it into the code emitter as separate entries, not as a composite pair.</div><div><br></div><div>For operands that aren't compile-time constants, the operand flag gets set in the expansion to the MOVT/MOVW instructions:</div><div><div> if (MO.isImm()) {</div><div> unsigned Imm = MO.getImm();</div><div> unsigned Lo16 = Imm & 0xffff;</div><div> unsigned Hi16 = (Imm >> 16) & 0xffff;</div><div> LO16 = LO16.addImm(Lo16);</div><div> HI16 = HI16.addImm(Hi16);</div><div> } else {</div><div> const GlobalValue *GV = MO.getGlobal();</div><div> unsigned TF = MO.getTargetFlags();</div><div> LO16 = LO16.addGlobalAddress(GV, MO.getOffset(), TF | ARMII::MO_LO16);</div><div> HI16 = HI16.addGlobalAddress(GV, MO.getOffset(), TF | ARMII::MO_HI16);</div><div> }</div><div><br></div><div>That's then marked with VK_ARM_LO16/VK_ARM_HI16 by ARMMCInstLower.cpp when it's looking at symbol reference operands.</div><div><br></div></div><div><br></div></div><blockquote type="cite"><div>At the current time, for the assembly printing,<br>MCAsmStreamer::EmitInstruction(const MCInst &Inst) calls out to<br> MCExpr::print(raw_ostream &OS)<br> which then calls out to MCSymbolRefExpr::getVariantKindName() to<br>print the magic :lower16: and :upper16: asm tags for .s emission<br>Currently, movt/movw emission works correctly in .s, but not in .o emission<br><br>This lead me to believe that the correct place to put the code to handle<br>MCSymbolRefExpr::VK_ARM_(HI||LO)16 for the .o path was to place a case<br>in getMachineOpValue() (i.e. not<br>ARMMCCodeEmitter::getBinaryCodeForInstr like I mistakenly wrote in my<br>prior email.)<br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Are you implying that the movt/movw instruction definition in the .td<br>files need to be fixed up instead to declare a new special case for .o<br>emission via the EncoderMethod string, for the .o emission of<br>movt/movw to be considered "correct"?<br></div></blockquote><div><br></div><div>A custom encoder may be the best way to differentiate the kinds of fixups we'll need for these operands (e.g., using LO16 may generate different fixups depending on which instruction it's used for, which implies different operand node types, and thus different encoder methods). In any case, the encoder, be it in getMachineOpValue() or a specialized method, will need to differentiate between an immediate operand and a symbol reference expression operand. In the latter case, it'll create a fixup for the lo/hi variantkind if one is present.</div><div><br></div><div>-Jim</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">On Nov 11, 2010, at 7:06 PM, Jason Kim wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Is getBinaryCodeForInst the best place to place the case for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">supporting movt/movw fixup emission?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The call stack seems to be:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#0 ARMMCCodeEmitter::getBinaryCodeForInstr<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#1 ARMMCCodeEmitter::EncodeInstruction<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#2 MCELFStreamer::EmitInstToData<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#3 MCObjectStreamer::EmitInstruction<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">#4 ARMAsmPrinter::EmitInstruction<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><arm-mc-elf-s08.patch>_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">llvm-commits mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote></div></blockquote></div><br></body></html>