Displaying 3 results from an estimated 3 matches for "mrm5m".
Did you mean:
mrm0m
2011 Jul 16
0
[LLVMdev] TableGen and DenseMap Strangeness
...!");
}
return Result->second;
}
If WORKS is defined, everything builds and tests fine. If it is not
defined, TableGen aborts with:
lib/Target/X86/X86InstrFPStack.td:212:10: error: In SUBR_FpI16m80: Operand $src1 does not appear in the instruction pattern
defm SUBR: FPBinary<fsub ,MRM5m, "subr">;
^
Anyone have a clue why the order of hashing might matter? I've made
sure no Inits are deleted anywhere so their memory should not be reused.
Valgrind reports a "clean" run aside from the gargantuan amount of
memory leaks.
Thanks for your help!...
2008 Apr 16
0
[LLVMdev] Being able to know the jitted code-size before emitting
...if (isX86_64ExtendedReg(MO))
> - REX |= 1 << Bit;
> - Bit++;
> - }
> - }
> - break;
> - }
> - case X86II::MRM0m: case X86II::MRM1m:
> - case X86II::MRM2m: case X86II::MRM3m:
> - case X86II::MRM4m: case X86II::MRM5m:
> - case X86II::MRM6m: case X86II::MRM7m:
> - case X86II::MRMDestMem: {
> - unsigned e = isTwoAddr ? 5 : 4;
> - i = isTwoAddr ? 1 : 0;
> - if (NumOps > e && isX86_64ExtendedReg(MI.getOperand(e)))
> - REX |= 1 << 2;
> - unsigned...
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
OK, here's a new patch that adds the infrastructure and the
implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize.
Both functions are virtual functions defined in TargetInstrInfo.h.
For X86, I moved some commodity functions from X86CodeEmitter to
X86InstrInfo.
What do you think?
Nicolas
Evan Cheng wrote:
>
> I think both of these belong to TargetInstrInfo. And