Re[2]: require assistance with emiting instructions

Alex Hill via gcc-help gcc-help@gcc.gnu.org
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 <jimw@sifive.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
>< gcc-help@gcc.gnu.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
>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.


More information about the Gcc-help mailing list