better loop support about llvm-mctoll

[bharadwajy]

Thank you very much!

Would really appreciate if you could create PR once you are happy with your changes. Please add C test sources to test/smoke_test to verify the changes proposed. I'll be happy to pull the changes up to master.

[Trass3r]

Btw what is the reason for that huge map? MCInst doesn't contain the width information?

[bharadwajy]

Btw what is the reason for that huge map? MCInst doesn't contain the width information?

Not at the time when I started the work. I did not see anything that indicates things have changed in that respect.

[Trass3r]

Hmm odd how do they represent something like mov DWORD PTR [rbp-0x4], edi then?

[Trass3r]

INC on memory is tricky though: inc DWORD PTR [rsp+rax*4-0x38]
Fails in

llvm-mctoll/X86/X86MachineInstructionRaiser.cpp

Line 1571 in 64f0e14

assert((SrcOp.isImm() || SrcOp.isReg()) &&

.
Operand 6 is "Metadata", 7 is register.
If I add

  if (MI.getOperand(SrcOpIndex).isMetadata())
    ++SrcOpIndex;

I get "Super register not found"
Any ideas?

[bharadwajy]

bool X86MachineInstructionRaiser::raiseMoveToMemInstr() is implemented to raise an instruction that moves to memory the content of an explicit source register or immediate value. So, that function is not designed to raise INCXXm instructions.

Support for INCXXm instructions is not yet implemented. That said, take a look at bool X86MachineInstructionRaiser::raiseNotOpMemInstr(). Basically that function generates an instruction to load from memory location, an operation (specifically, not) instruction and an instruction to store to the memory location. This may be an opportunity to expand the class NOT_OP_MEM (to say INPLACE_MEM_OP) to raise instructions that load, operate and store.

[bharadwajy]

Btw what is the reason for that huge map? MCInst doesn't contain the width information?

Not at the time when I started the work. I did not see anything that indicates things have changed in that respect.

However, eventually, I really want to get rid of the burden of maintaining this table and replace its services using LLVM APIs or some other tblgen based utility.

[Trass3r]

This may be an opportunity to expand the class NOT_OP_MEM (to say INPLACE_MEM_OP) to raise instructions that load, operate and store.

Thanks that helped! Trass3r@f100b2e

I really want to get rid of the burden of maintaining this table and replace its services using LLVM APIs or some other tblgen based utility.

I experimented a bit with that (see my repo) but I think it would require some refactoring of the raise functions into something more generic working on general a = b op c instructions with common and transparent handling of reg/mem/imm operands.