~smlckz


#673 haredoc -Fhtml: descriptions are truncated at the end by a few characters 3 months ago

Ticket created by ~smlckz on ~sircmpwn/hare

#467 tests/01-arrays.s:2805: Error: immediate cannot be moved by a single instruction 1 year, 1 month ago

Comment by ~smlckz on ~sircmpwn/hare

Same qbe problem we faced before. Instruction length in ARM is fixed, so is the allowed size of immediate value in any instruction. To fix this and similiar problems we might face in the future once and for all, we need to account for the maximum immediate value for all the instructions we use and check if any value outside that limit is given so as to emit necessary instruction to avoid this limit.

#464 Equality check with math::isnan does not behave as expected 1 year, 1 month ago

Comment by ~smlckz on ~sircmpwn/hare

The example is reducible to:

fn test(n: f32) bool = n == 0.0 || n != n;

export fn main() void = {
        assert(test(0.0));
        assert(test(0.0 / 0.0));
        assert(!test(1.0));
};

This works fine in aarch64 without any problems.

In x86_64, we get the following assembly, commented where it goes wrong:

.section ".text.test", "ax"
test:
	pushq %rbp
	movq %rsp, %rbp
	/* ucomiss sets ZF, clears PF and CF when both arguments are equal */
	ucomiss .Lfp0(%rip), %xmm0
	/* %al <- ZF */
	setz %al
	movzbl %al, %eax
	/* %cl <- !PF */
	setnp %cl
	movzbl %cl, %ecx
	/* now eax <- ZF && !PF */
	andl %ecx, %eax
	/* eax = 0 when arguments to ucomiss are unequal,
	   so we should try next comparison, but the following
	   jz will cause the flow leave the function which
	   makes the expression act like an AND instead of OR
	   Expression written: n == 0.0 || n != n
	   Expression generated: n == 0.0 && n != n
	   And vice-versa!
	 */
	jz .Lbb3
	ucomiss %xmm0, %xmm0
	setnz %al
	movzbl %al, %eax
	setp %cl
	movzbl %cl, %ecx
	orl %ecx, %eax
.Lbb3:
	leave
	ret
/* end function test */

.section ".data.strdata.30"
.balign 8
strdata.30:
	.ascii "Assertion failed: ../nantp.ha:4:1"
/* end data */

.section ".data.strdata.42"
.balign 8
strdata.42:
	.ascii "Assertion failed: ../nantp.ha:5:1"
/* end data */

.section ".data.strdata.53"
.balign 8
strdata.53:
	.ascii "Assertion failed: ../nantp.ha:6:1"
/* end data */

.section ".text.main", "ax"
.globl main
main:
	pushq %rbp
	movq %rsp, %rbp
	sub $80, %rsp
	movss .Lfp0(%rip), %xmm0
	callq test
	leaq strdata.30(%rip), %rcx
	movq %rcx, -72(%rbp)
	movq $33, -64(%rbp)
	movq $33, -56(%rbp)
	cmpl $0, %eax
	jnz .Lbb7
	subq $32, %rsp
	movq %rsp, %rcx
	movq -56(%rbp), %rax
	movq %rax, 16(%rcx)
	movq -64(%rbp), %rax
	movq %rax, 8(%rcx)
	movq -72(%rbp), %rax
	movq %rax, 0(%rcx)
	callq rt.abort
	subq $-32, %rsp
.Lbb7:
	movss .Lfp0(%rip), %xmm0
	divss .Lfp0(%rip), %xmm0
	callq test
	leaq strdata.42(%rip), %rcx
	movq %rcx, -48(%rbp)
	movq $33, -40(%rbp)
	movq $33, -32(%rbp)
	cmpl $0, %eax
	jnz .Lbb9
	subq $32, %rsp
	movq %rsp, %rcx
	movq -32(%rbp), %rax
	movq %rax, 16(%rcx)
	movq -40(%rbp), %rax
	movq %rax, 8(%rcx)
	movq -48(%rbp), %rax
	movq %rax, 0(%rcx)
	callq rt.abort
	subq $-32, %rsp
.Lbb9:
	movss .Lfp1(%rip), %xmm0
	callq test
	xorl $1, %eax
	leaq strdata.53(%rip), %rcx
	movq %rcx, -24(%rbp)
	movq $33, -16(%rbp)
	movq $33, -8(%rbp)
	cmpl $0, %eax
	jnz .Lbb11
	subq $32, %rsp
	movq %rsp, %rcx
	movq -8(%rbp), %rax
	movq %rax, 16(%rcx)
	movq -16(%rbp), %rax
	movq %rax, 8(%rcx)
	movq -24(%rbp), %rax
	movq %rax, 0(%rcx)
	callq rt.abort
	subq $-32, %rsp
.Lbb11:
	leave
	ret
/* end function main */

/* floating point constants */
.data
.balign 4
.Lfp0:
	.int 0 /* 0.000000 */
.balign 4
.Lfp1:
	.int 1065353216 /* 1.000000 */
.section .note.GNU-stack,"",@progbits

So, I think the problem is in qbe, when it generates assembly for x86_64.

#54 Implement floating-point constants/literals & operations 1 year, 3 months ago

Comment by ~smlckz on ~sircmpwn/hare

export def INF: f32 = 1.0 / 0.0;

gives me: Assertion failed: 0 (src/eval.c: itrunc: 104).

So, we don't have the translation-time evaluation of expressions with floating-point constants yet. [See harec/src/eval.c: function eval_binarithm]

Not opening a seperate ticket because I think this ticket covers this issue as well.

#387 qbe bug: aarch64: hare_unparse.s:635: Error: immediate offset out of range 1 year, 3 months ago

Comment by ~smlckz on ~sircmpwn/hare

I don't think we'd need to clobber and restore registers in this case. I think we can use ILP0 (R16) or ILP1 (R17) instead, like what we did for clobbering/restoring extra registers for using them in functions in the prologue/epilogue.

#387 qbe bug: aarch64: hare_unparse.s:635: Error: immediate offset out of range 1 year, 3 months ago

Comment by ~smlckz on ~sircmpwn/hare

This time it's a deeper problem. I'm currently using a hacky solution: http://ix.io/2Zjh When make fails at arm64/emit.c, try again with make CFLAGS=-std=gnu99

As ~mcf is also working on riscv64, another RISC architecture target with similiar constraints on machine code instruction encoding, I hope to see a better solution from ~mcf.

#326 harec: allow casting rune directly into an integral type 1 year, 4 months ago

Ticket created by ~smlckz on ~sircmpwn/hare

Currently, to convert a rune into a integral type one needs to cast it to u32 first and then the desired integral type, e.g. '\n': u32: u8 to convert the newline into a byte. Solving this would allow us to to that without the intermediate cast: '\n': u8.

#320 harec: promotion of smaller integer operand of addition doesn't happen 1 year, 4 months ago

Ticket created by ~smlckz on ~sircmpwn/hare

harec should have emitted cast to promote u8 to u64 in the following code. Not doing that, and using the non-casted value as an operand of add instruction in generated IR, qbe rejects the that with test.ssa:76: invalid type for second operand %rvalue.26 in add.

https://paste.sr.ht/~smlckz/1830c74233e77717d2d6bbb3dd650f8539dc894f