[PATCH] [mips] [IAS] Fix negation of 32-bit immediates.

Daniel Sanders daniel.sanders at imgtec.com
Tue Apr 7 07:10:16 PDT 2015


I think we're attacking this in the wrong place at the moment. It's difficult to tell without going deep into the guts of the matcher but it's important to the operation of the parser that we don't specialize our operands too early since there's no facility for backtracking.

This was a particular problem for floating point registers a while back. The parser would identify register names like '$f0' as being an F0_64 and having committed to that interpretation would then fail to match FGR32 versions of the instructions. In our current implementation, our floating point operand for $f0 is all three of F0, D0, and F0_64 (it's stored as a register index that permits FGR32, FGR64, and AFGR64 contexts) until the operand is rendered into an instruction which specializes it to a single register. The same needs to be true of integers, we need to have a generic 64-bit integer which is specialized into other integer types when it's rendered into an instruction.

If the instruction were expanded by the tablegen-erated matcher, we could attack this in tablegen using an AsmOperandClass. The PredicateMethod would determine whether the value was a valid unsigned/signed 32-bit integer (which is the case when it fits in a _33_-bit signed integer). Then if the instruction matched, the RenderMethod would adjust the value so that the excess bits are a sign-extension of the 32-bit value. So for example, 0x0000000080000000 would return true for the PredicateMethod and be converted to 0xffffffff80000000 by the RenderMethod.

I'd therefore suggest that expandLoadImm() have some way of knowing whether the context for the integer is 32-bit or 64-bit. When called in a 32-bit context, it would convert the value to a signed 32-bit integer before emitting the code to produce it.


http://reviews.llvm.org/D8662

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list