I understand my mistake, insn works but it fail assembler test while it not exist in binutils, and/or conflict with LD insn 64-bit insn. I appreciate for help! >Пятница, 31 мая 2019, 23:59 +05:00 от Jim Wilson <jimw@xxxxxxxxxx>: > >There isn't enough info here to give good answers. We need more details. > >On Fri, May 31, 2019 at 4:13 AM Alex Hill via gcc-help >< gcc-help@xxxxxxxxxxx > wrote: >> (define_insn "*<GPR:mode>_load_index" >>... >> i create some kind of instruction but it will emit only on 32bit system, i use it for risc-v 64 >This isn't a standard named pattern. Did you add code someplace to >call it? You didn't show us that code. Maybe there is a bug in that >code. > >> when i try use 64-bit it will not emit, if i try const_int 8 GCC wont even compile. > >Why does it fail to compile when using const_int 8? What is the exact >error message? > >Adding a pattern for this looks like an unusual way to implement this. >If this is intended to be supported by every load/store instruction, >then you should add a new addressing mode. See for instance >riscv_legitimate_address_p and riscv_classify_address. If this is >only supported by some load/store instructions, then it may still be >useful to add a new addressing mode, but you would then need to add >new predicates and constraints so that you can limit the new >addressing mode to only those instructions that support it. > >In your pattern, you have (match_operand:GPR 0 "register_operand" >"=r,m"), but m is for memory operands, and a memory operand can't be a >register operand. So these should all just be r without m. An >explicit mem in a pattern is generally not a good way to do this >though. You would likely be better off with new addressing modes as >mentioned above. > >Jim Kind regards Alex Hill.
