[PATCH] [RFC PATCH] BPF backend

[Alexei Starovoitov]

On Wed, Dec 3, 2014 at 3:11 PM, Tom Stellard <tom at stellard.net> wrote:
> On Wed, Dec 03, 2014 at 02:50:41PM -0800, Alexei Starovoitov wrote:
>> On Wed, Dec 3, 2014 at 1:53 PM, Tom Stellard <thomas.stellard at amd.com> wrote:
>> > Comment at: lib/Target/BPF/MCTargetDesc/BPFMCCodeEmitter.cpp:127-147
>> > @@ +126,23 @@
>> > +
>> > +  if (Opcode == BPF::LD_imm64) {
>> > +    uint64_t Value = getBinaryCodeForInstr(MI, Fixups, STI);
>> > +    EmitByte(Value >> 56, CurByte, OS);
>> > +    EmitByte(((Value >> 48) & 0xff), CurByte, OS);
>> > +    EmitLEConstant(0, 2, CurByte, OS);
>> > +    EmitLEConstant(Value & 0xffffFFFF, 4, CurByte, OS);
>> > +
>> > +    const MCOperand &MO = MI.getOperand(1);
>> > +    uint64_t Imm = MO.isImm() ? MO.getImm() : 0;
>> > +    EmitByte(0, CurByte, OS);
>> > +    EmitByte(0, CurByte, OS);
>> > +    EmitLEConstant(0, 2, CurByte, OS);
>> > +    EmitLEConstant(Imm >> 32, 4, CurByte, OS);
>> > +  } else {
>> > +    // Get instruction encoding and emit it
>> > +    uint64_t Value = getBinaryCodeForInstr(MI, Fixups, STI);
>> > +    EmitByte(Value >> 56, CurByte, OS);
>> > +    EmitByte((Value >> 48) & 0xff, CurByte, OS);
>> > +    EmitLEConstant((Value >> 32) & 0xffff, 2, CurByte, OS);
>> > +    EmitLEConstant(Value & 0xffffFFFF, 4, CurByte, OS);
>> > +  }
>> > +}
>> > ----------------
>> > Why can't you just emit the value returned by getBinaryCodeForInstr() directly without re-ordering the bytes?
>>
>> It's easier to encode all bits of insn in BPFInstrInfo.td this way.
>> Right now it emits right thing for little endian only, but encoding should
>> be big if underlying cpu is big-endian. So more 'if' conditions will
>> be added here in the future.
>>
>
> There might be a way to have LLVM emit with the correct endianness for you.
> AArch64 has big and little endian targets, might want to see what it does.
>

hmm. looks like aarch64 is generalizing byteswap as part of emitInst()
MCTargetDesc/AArch64ELFStreamer.cpp:124
whereas I do it more directly, since not the whole 8 byte insn
needs a flip. Also LD_imm64 insn is the only 16 byte insn,
so I special case it during emission.
Will play with it more and will check what other bi-endian archs do.