在 2022/11/4 上午10:22, Xi Ruoyao 写道:
On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote:
gcc/ChangeLog:
* config/loongarch/constraints.md (x): New constraint.
* config/loongarch/loongarch.cc (struct loongarch_address_info):
Adds a method to load the immediate 32 to 64 bit field.
(struct loongarch_integer_op): Define a new member curr_value,
that records the value of the number stored in the destination
register immediately after the current instruction has run.
(LARCH_MAX_INTEGER_OPS): Define this macro as 3.
(LU32I_B): Move to the loongarch.h.
(LU52I_B): Likewise.
(loongarch_build_integer): Adds a method to load the immediate
32 to 63 bits.
(loongarch_move_integer): Likewise.
We need to mention "call set_unique_reg_note" here because it seems the
key to resolve the issue.
During debugging, I found the problem because the source register and
destination
register of the lu32i.d instruction are the same. As a result, during
loop2_invariant pass,
the destination register of lu32i.d is used twice, so the instructions
after this instruction
will not be brought out of the loop.
Therefore, I combined lu32i.d and lu52i.d into one template, which
avoids the situation
that the same register is used twice. It is not split into two
instructions until loop2_invariant has
been optimized. So I don't think "set_unique_reg_note" plays a decisive
role in this optimization.
Otherwise LGTM.
(loongarch_print_operand_reloc): Modifying comment information.
* config/loongarch/loongarch.h (LU32I_B): Move from loongarch.cc.
(LU52I_B): Likewise.
(HWIT_UC_0xFFFFFFFF): New macro.
(HI32_OPERAND): New macro.
* config/loongarch/loongarch.md (load_hi32): New template.
* config/loongarch/predicates.md (const_hi32_operand): Determines
whether the value is an immediate number that has a value of only
the higher 32 bits.
(hi32_mask_operand): Immediately counts the mask of 32 to 61 bits.
