Re: require assistance with emiting instructions
Alex Hill via gcc-help
Mon Jun 3 05:17:00 GMT 2019
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 <email@example.com>:
>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
>< firstname.lastname@example.org > 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
>> 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
>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
Kind regards Alex Hill.
More information about the Gcc-help