LoongArch: gas: add support using variable for li.w/d#215
LoongArch: gas: add support using variable for li.w/d#215Calring wants to merge 1 commit intoloongson:masterfrom
Conversation
|
|
||
| primary_expression | ||
| : INTEGER {emit_const ($1);} | ||
| | IDENTIFIER {emit_const_var ($1);} |
There was a problem hiding this comment.
Judging from this, isn't the change applicable to more insns than li.[wd] alone?
There was a problem hiding this comment.
You're exactly right. Let me fix this again to only works for li.w./d
There was a problem hiding this comment.
You're exactly right. Let me fix this again to only works for li.w./d
No no no. In its current form it's way more ergonomic. I for example would be very surprised to find out that variable substitution only works for li.[wd], I'd curse loudly for the anti-feature.
There was a problem hiding this comment.
I mean you'd simply write more test cases to showcase the usage with a wide variety of insns, and reword the commit message. Just don't restrict to li only.
There was a problem hiding this comment.
As we know, the li.[wd] is a macro instruction used to load immediate. li.w can load 32 bits immediate, and li.d can load 64 bits immediate. If a programmer need to load immediate, li.[wd] is completely competent. If other instructions also support, for programmer who don't know instructions immediate bits width, It is easy to make mistakes . For eaxmple, addi.[wd] rd, rj, var can only load 12 bits width immediate, if var bits width exceeds 12, it will be not work. So support li.[wd] is enough, that's my thought.
There was a problem hiding this comment.
I think in that case you may want to improve the error message so the user is hinted towards li.[wd]. Inconsistency is not good for learners, despite your good intention. It is bound to cause confusion, believe me...
There was a problem hiding this comment.
Oh, I got you, you're right. I will add more testcases for other instructions.
There was a problem hiding this comment.
I've tested this feature of other ARCHs like x86, their behavior is really the same as you said!!!That's cool!
There was a problem hiding this comment.
I've tested this feature of other ARCHs like x86, their behavior is really the same as you said!!!That's cool!
Told you. ;-)
Instructions that can load immediate support using constant
variable like ".equ var, 123 li.w/d resgister, var".
gas/
* config/loongarch-parse.y
* config/tc-loongarch.c
Add two testcases.One is a program using constant variable,
another test almost all instructions that can load immediate.
gas/
* testsuite/gas/loongarch/li.d
* testsuite/gas/loongarch/li.s
* testsuite/gas/loongarch/imm_ins.d
* testsuite/gas/loongarch/imm_ins.s
|
LoongArch: gas: add support using constant variable in instructions. gas/ gas/ |
| as_bad("illegal operand: %s", op); | ||
| top->value.X_op = O_constant; | ||
| top->value.X_add_number = ep.X_add_number; | ||
| top->type = BFD_RELOC_LARCH_SOP_PUSH_ABSOLUTE; |
There was a problem hiding this comment.
Does this mean the resulting object file will have this reloc record? Because we may be working with lld/mold that cannot process stack-based relocations, in which case we actually want to substitute the value in, as if the user had written the concrete value in the respective slot. Otherwise the approach is mostly okay.
There was a problem hiding this comment.
Once it is recognized as a constant, it will discarded this reloc in subsequent processing, and obviously object file will have not this reloc record.
2 participants
gas/
* config/loongarch-parse.y
* config/tc-loongarch.c
gas/
* testsuite/gas/loongarch/li.d
* testsuite/gas/loongarch/li.s
* testsuite/gas/loongarch/li2.d
* testsuite/gas/loongarch/li2.s