Re[2]: require assistance with emiting instructions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





>Пятница, 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

Forget about `m`, now im̀ using this:

(define_insn "*<GPR:mode>_load_indexed"
[
(set
(match_operand:GPR 0 "register_operand" "=r")
(mem:GPR
(plus:GPR
(mult:GPR
(match_operand:GPR 1 "register_operand" "%r")
(const_int 8))
(match_operand:GPR 2 "register_operand" "r"))))
]
""
"ld %0, (%2, %1)"
[(set_attr "mode" "<MODE>")]
) When i use const int 8 GCC crashes when try to compile with this message:

riscv64-unknown-elf-ar cru lib.a lib_a-errno.o riscv64-unknown-elf-ranlib lib.a
/tmp/cceJqraN.s: Assembler messages:/tmp/cceJqraN.s:203: Error: found ',', expected: ')'/tmp/cceJqraN.s:203: Error: illegal operands `ld a0,(s2,a0)'
/tmp/cceJqraN.s:265: Error: found ',', expected: ')'
/tmp/cceJqraN.s:265: Error: illegal operands `ld a0,(s2,a0)'
Makefile:346: ошибка выполнения рецепта для цели «lib_a-__dprintf.o»

ошибка выполнения рецепта means error recipe execution.

im̀ using riscv-gnu-toolchain NEWLIB with default flags, compile with dual xeon X5670 128Gb RAM with flag ´-j´, its never been used more than 56gigs of RAM.

When i try to compile GCC with const_int 4 in .md, it builds successfully, but gcc emit insn only in 32-bit mode, when i compile .c code via risc64-unknown-elf-gcc with flags -march=rv32gc -mabi=ilp32d, if i try to use default flags, except -O2 of course, gcc never emits insn, both for int and long typeof. The test code looks like:

int foo( int a, int foobar[], int n)
{
    a = foobar[n];
} As i understand, in case of 64 bit, i need to shift of 0x3 or mult of 8, i cant understand what i dont understand.

Help me Jim Wilson, you are my only hope!


Kind regards Alex Hill.




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux