Skip to content

16 bit load generated in z80 mode #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hansake opened this issue Jul 22, 2021 · 2 comments
Closed

16 bit load generated in z80 mode #22

hansake opened this issue Jul 22, 2021 · 2 comments
Assignees
Labels
bug Something isn't working miscompile Incorrect code was generated

Comments

@hansake
Copy link

hansake commented Jul 22, 2021

When compiling a very simple test program for z80 an incorrect 16 bit indexed load is generated by the compiler.
This was correct in earlier version.

The test program:

/* Very very simple test program: testz80.c
 */
int main() {
    int a , b, c;

    b = 1;
    c = 2;
    a = b + c;
    return (a);
}

Compiled with:

$ ez80-clang --target=z80 -S testz80.c

gave in a previous release this output:

        section	.text,"ax",@progbits
	section	.text,"ax",@progbits
	public	_main
_main:
	push	ix
	ld	ix, 0
	add	ix, sp
	ld	hl, -8
	add	hl, sp
	ld	sp, hl
	ld	hl, 0
	ld	de, 1
	ld	bc, 2
	ld	(ix + -2), l
	ld	(ix + -1), h
	ld	(ix + -6), e
	ld	(ix + -5), d
	ld	(ix + -8), c
	ld	(ix + -7), b
	ld	l, (ix + -6)
	ld	h, (ix + -5)
	ld	e, (ix + -8)
	ld	d, (ix + -7)
	add	hl, de
	ld	(ix + -4), l
	ld	(ix + -3), h
	ld	l, (ix + -4)
	ld	h, (ix + -3)
	ld	iy, 8
	add	iy, sp
	ld	sp, iy
	pop	ix
	ret
	section	.text,"ax",@progbits

	ident	"clang version 13.0.0 (https://github.com/jacobly0/llvm-project.git d270916c9cf31e630cc9ef215671a0d1c56280f8)"
	extern	__Unwind_SjLj_Register
	extern	__Unwind_SjLj_Unregister

and in the latest release I cloned and compiled, the following assembler output is generated.

	section	.text,"ax",@progbits
	section	.text,"ax",@progbits
	public	_main
_main:
	push	ix
	ld	ix, 0
	add	ix, sp
	ld	hl, -8
	add	hl, sp
	ld	sp, hl
	ld	hl, 0
	ld	de, 1
	ld	bc, 2
	ld	(ix - 2), l
	ld	(ix - 1), h
	ld	(ix - 6), e
	ld	(ix - 5), d
	ld	(ix - 8), c
	ld	(ix - 7), b
	ld	l, (ix - 6)
	ld	h, (ix - 5)
	ld	e, (ix - 8)
	ld	d, (ix - 7)
	add	hl, de
	ld	(ix - 4), l
	ld	(ix - 3), h
	ld	hl, (ix - 4) <--- incorrect instruction
	ld	iy, 8
	add	iy, sp
	ld	sp, iy
	pop	ix
	ret
	section	.text,"ax",@progbits

	ident	"clang version 13.0.0 (https://github.com/jacobly0/llvm-project.git a25003f240988428e2fad6f77f25d9b600c59b5e)"
	extern	__Unwind_SjLj_Register
	extern	__Unwind_SjLj_Unregister

The instruction that upsets the assembler (z80-elf-as) is:

	ld	hl, (ix - 4)

which is correctly generated in an earlier release as:

	ld	l, (ix + -4)
	ld	h, (ix + -3)

Unfortunately Z80 and Z180 can't make a 16 bit indexed load.

Another thing that z80-elf-as don't understand is:

	public	_main

but that was fixed with a sed script used by the Makefile:

...Makefile
# Define a pattern rule that compiles every .c file into a .o file
%.o : %.c
	ez80-clang --target=z180 -S -o $<.is $<
	sed -f asmscript.sed $<.is >  $<.s
	z80-elf-as -march=z180 -o $@ $<.s
	rm $<.is $<.s
...asmscript.sed
s/\tpublic/\tglobal/
@hansake hansake closed this as completed Sep 5, 2021
@hansake hansake reopened this Sep 5, 2021
@jacobly0 jacobly0 self-assigned this Jan 30, 2022
@jacobly0 jacobly0 added the bug Something isn't working label Jan 30, 2022
@jacobly0
Copy link
Owner

Sorry, I was in the middle of moving and forgot to fix this.

@jacobly0 jacobly0 changed the title Incorrext 16 bit indexed load generated, was correct in an earlier release 16 bit load generated in z80 mode Jan 30, 2022
jacobly0 added a commit that referenced this issue Jan 30, 2022
@jacobly0 jacobly0 added miscompile Incorrect code was generated bug Something isn't working and removed bug Something isn't working labels Jan 31, 2022
@hansake
Copy link
Author

hansake commented Jan 31, 2022

Works good now. Thanks.

jacobly0 pushed a commit that referenced this issue Nov 20, 2024
…onger cause a crash (llvm#116569)

This PR fixes a bug introduced by llvm#110199, which causes any half float
argument to crash the compiler on MIPS64.

Currently compiling this bit of code with `llc -mtriple=mips64`: 
```
define void @half_args(half %a) nounwind {
entry:
        ret void
}
```

Crashes with the following log:
```
LLVM ERROR: unable to allocate function argument #0
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: llc -mtriple=mips64
1.	Running pass 'Function Pass Manager' on module '<stdin>'.
2.	Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@half_args'
 #0 0x000055a3a4013df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32d0df8)
 #1 0x000055a3a401199e llvm::sys::RunSignalHandlers() (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32ce99e)
 #2 0x000055a3a40144a8 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f00bde558c0 __restore_rt libc_sigaction.c:0:0
 #4 0x00007f00bdea462c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007f00bde55822 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #6 0x00007f00bde3e4af abort ./stdlib/abort.c:81:7
 #7 0x000055a3a3f80e3c llvm::report_fatal_error(llvm::Twine const&, bool) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x323de3c)
 #8 0x000055a3a2e20dfa (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x20dddfa)
 #9 0x000055a3a2a34e20 llvm::MipsTargetLowering::LowerFormalArguments(llvm::SDValue, unsigned int, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::SDLoc const&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const MipsISelLowering.cpp:0:0
#10 0x000055a3a3d896a9 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30466a9)
#11 0x000055a3a3e0b3ec llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c83ec)
#12 0x000055a3a3e09e21 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c6e21)
#13 0x000055a3a2aae1ca llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) MipsISelDAGToDAG.cpp:0:0
#14 0x000055a3a3e07706 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c4706)
#15 0x000055a3a3051ed6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x230eed6)
#16 0x000055a3a35a3ec9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x2860ec9)
#17 0x000055a3a35ac3b2 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x28693b2)
#18 0x000055a3a35a499c llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x286199c)
#19 0x000055a3a262abbb main (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x18e7bbb)
#20 0x00007f00bde3fc4c __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#21 0x00007f00bde3fd05 call_init ./csu/../csu/libc-start.c:128:20
#22 0x00007f00bde3fd05 __libc_start_main@GLIBC_2.2.5 ./csu/../csu/libc-start.c:347:5
#23 0x000055a3a2624921 _start /builddir/glibc-2.39/csu/../sysdeps/x86_64/start.S:117:0
```

This is caused by the fact that after the change, `f16`s are no longer
lowered as `f32`s in calls.

Two possible fixes are available:
- Update calling conventions to properly support passing `f16` as
integers.
- Update `useFPRegsForHalfType()` to return `true` so that `f16` are
still kept in `f32` registers, as before llvm#110199.

This PR implements the first solution to not introduce any more ABI
changes as llvm#110199 already did.

As of what is the correct ABI for halfs, I don't think there is a
correct answer. GCC doesn't support halfs on MIPS, and I couldn't find
any information on old MIPS ABI manuals either.
adriweb pushed a commit to CE-Programming/llvm-project that referenced this issue Feb 26, 2025
adriweb pushed a commit to CE-Programming/llvm-project that referenced this issue Feb 26, 2025
adriweb pushed a commit to CE-Programming/llvm-project that referenced this issue Feb 27, 2025
adriweb pushed a commit to CE-Programming/llvm-project that referenced this issue Feb 27, 2025
adriweb pushed a commit to CE-Programming/llvm-project that referenced this issue Mar 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working miscompile Incorrect code was generated
Projects
None yet
Development

No branches or pull requests

2 participants