Friendly ping.

Thanks.

@RKSimon rebase done.

Thanks.

Rebase.

Simplify test cases.

Rebase.

Move the case into test/CodeGen/LoongArch/ir-instruction/and.ll.

Rebase.

Add LA64 to test file.

Rebase.

Add LA32 to test case.

1. Update test case.
2. Update description.

1. Move to a new test file.
2. Add RV64I to test file.

Rebase and update test case.

Rebase and update test case.

Add a test case.

Thanks.

Thanks for your comments.

1. Update to use untyped immediate operand in select patterns.
2. Add test cases.

Thanks.

Update test case.

Add test cases.

Just like in the Linux kernel, In bare-metal development with Rust, there is also need for compiling targets with software floating-point support to access the floating-point context through hardware floating-point instructions, potentially even within Rust's inline assembly. This should be one of the ways to address the problem.

Grateful for your contribution.

Thank you. I tested it on Rust bare-metal target and works. :-)

AFAIK we just need

CFLAGS_fpu.o  = -mabi=lp64s
CFLAGS_REMOVE_fpu.o = -msoft-float

Thanks!

@MaskRay Sorry, I missed the comment. :)

In D81908#2104333, @atanasyan wrote:

LGTM

In D81919#2097431, @xiangzhai wrote:

Just workaround as GNU toolchain:

$ objdump -dr t.llvm.o 

t.llvm.o:     file format elf64-tradlittlemips


Disassembly of section .text:

0000000000000000 <main>:
   0:	00000000 	nop
   4:	67f9fffc 	daddiu	t9,ra,-4
   8:	67f90000 	daddiu	t9,ra,0
	...
			10: R_MIPS_32	main
			10: R_MIPS_NONE	*ABS*
			10: R_MIPS_NONE	*ABS*

The ExprKind of main - . is ExprKind::Binary, but GNU toolchain treat it as %lo(main - .), because ORI and DADDIU only have the 16-bit signed immediate!

So just workaround ExprKind::Binary to ExprKind::Target for BAD relocation directive N64 testcase.

Thanks for review.

In D81919#2095516, @xiangzhai wrote:

Behaviour the same as GNU toolchain:

$ objdump -r t.llvm.o 

t.llvm.o:     file format elf64-tradlittlemips

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
000000000000000c R_MIPS_32         main
000000000000000c R_MIPS_NONE       *ABS*
000000000000000c R_MIPS_NONE       *ABS*

The same ABS value -4:

$ objdump -D t.llvm.o 

t.llvm.o:     file format elf64-tradlittlemips


Disassembly of section .text:

0000000000000000 <main>:
   0:	00000000 	nop
   4:	67f9fffc 	daddiu	t9,ra,-4

In D81908#2095524, @atanasyan wrote:

In D81908#2095355, @xiangzhai wrote:

In D81908#2095335, @atanasyan wrote:

Does this patch depend on D81919?

No!

But both patches change content of the same if (Kind == MCExpr::SymbolRef) statement.

Thanks for review.

So do we need to maintain the same behavior as the GNU toolchain? The current behavior of including constraints is correct, and it seems clear to use explicit constraints, isn't it?

It is not enough to just skip the generation of fixup, because we did not calculate the sub-expression of operand 3 of the daddiu instruction, so after linking, the immediate encoding of daddiu is also incorrect:

Add a unit test case.