[llvm-commits] [PATCH] x86 code emitter improvements for object files

[Bruno Cardoso Lopes]

On Mon, Aug 3, 2009 at 4:00 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Jul 31, 2009, at 4:03 PM, Bruno Cardoso Lopes wrote:
>
>> Hi all,
>>
>> The X86CodeEmitter has the following behaviour:
>>
>> 1) When emiting displacements:
>> - Only use pc_relative relocations for x86_64 (globals, cstpools and
>> jmptables)
>> - For x86, only uses pc_rel ou pic_re
>> This two items above do not always work for ELF.
>
> Hi Bruno,
>
> I don't have an opinion about this patch specifically, but would it be
> possible to make the code emitter be driven off the asm operand flags
> instead of making equivalent decisions that have to mirror what isel does?
>
> Specifically, MO.getTargetFlags() should tell the code emitter how to handle
> the CPI/JT/GA/ExtSym operands, X86ATTAsmPrinter.cpp has stuff like this:
>
>  switch (MO.getTargetFlags()) {
>  default:
>    llvm_unreachable("Unknown target flag on GV operand");
>  case X86II::MO_NO_FLAG:    // No flag.
>    break;
>  case X86II::MO_DARWIN_NONLAZY:
>  case X86II::MO_DARWIN_HIDDEN_NONLAZY:
>  case X86II::MO_DLLIMPORT:
>  case X86II::MO_DARWIN_STUB:
>    // These affect the name of the symbol, not any suffix.
>    break;
>  case X86II::MO_GOT_ABSOLUTE_ADDRESS:
>    O << " + [.-";
>    PrintPICBaseSymbol();
>    O << ']';
>    break;
>  case X86II::MO_PIC_BASE_OFFSET:
>  case X86II::MO_DARWIN_NONLAZY_PIC_BASE:
>  case X86II::MO_DARWIN_HIDDEN_NONLAZY_PIC_BASE:
>    O << '-';
>    PrintPICBaseSymbol();
>    break;
>  case X86II::MO_TLSGD:     O << "@TLSGD";     break;
>  case X86II::MO_GOTTPOFF:  O << "@GOTTPOFF";  break;
>  case X86II::MO_INDNTPOFF: O << "@INDNTPOFF"; break;
>  case X86II::MO_TPOFF:     O << "@TPOFF";     break;
>  case X86II::MO_NTPOFF:    O << "@NTPOFF";    break;
>  case X86II::MO_GOTPCREL:  O << "@GOTPCREL";  break;
>  case X86II::MO_GOT:       O << "@GOT";       break;
>  case X86II::MO_GOTOFF:    O << "@GOTOFF";    break;
>  case X86II::MO_PLT:       O << "@PLT";       break;
>  }
>
> For example.  It would be better to base the encoding on this flag than
> checking things like Is64BitMode, IsPIC etc.

Yes, that's the right way to go. I thought about that when I started hacking the
x86 code emitter, but the problem here is that I'm afraid of breaking JIT stuff
and lose the focus on the elf object code emission. I would be happy to
work on this clean up as a next step after elf is working, but I would
prefer to
apply this patch for now if that's ok for you. But it's your call then.

Thanks,

>> This patch try to solve the 3 problems above to properly emit elf
>> binaries for x86/x86_64. With
>> this changes applied (together with elf improvements I've not commited
>> yet) I was able
>> to run 209/243 (83%) of SinglesSources using ELF object files emited by
>> LLC :)
>> and with no regressions for JIT.
>
> Wow, nice!!
>
> -Chris
>
>



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc