[Mono-dev] [PATCH]: Fix abort when generating sparc V9 code

[David Miller]

From: "Zoltan Varga" <vargaz at gmail.com>
Date: Fri, 2 Nov 2007 16:36:02 +0100

> This is now in SVN.

Thanks Zoltan.

I have some MONO Sparc changes I've been working on to improve
code generation.  For example, I've copied the idea from the
PPC et al. ports to have a lowering pass right before register
allocation to improve handling of out-of-range immediate fields
so that the code emitter can be more simple and only consider
the cases where the immediate fields fit.

And as a result the sparc JIT now supports indexing loads and
stores.

This work is done and the testsuite has no regressions for sparc
32-bit, I'll be testing 64-bit soon.

I'm also going to add more cases to the peephole pass on Sparc.
For example, there are a lot of simple things not caught like
transforming:

	sethi	%hi(foo), %reg2		! OP_ICONST
	or	%reg2, %lo(foo), %reg2
	ld	[%reg2 + 0], %dest_reg	! OP_LOAD_MEMBASE

into:

	sethi	%hi(foo), %reg2			! OP_ICONST
	ld	[%reg2 + %lo(foo)], %dest_reg	! OP_LOAD_MEMBASE

This will require first lowering the "sethi + or" into seperate
operations (OP_ICONST, OP_OR_IMM) and then looking for this
"OP_OR_IMM, OP_{LOAD,STORE}_*" pattern.

OP_LOADU4_MEM could be decomposed similarly.

Next, I have a design in my head and plans for branch delay
slot filling.  At the very least it should be able to fill
branch delay slots using instructions from the same basic
block.  Ie. simple cases like transforming:

	add	%reg, 1, %reg
	bcond	label
	 nop

into:

	bcond	label
	 add	%reg, 1, %reg

For example.  This lack of delay slot filling (and the fact that the
branches are all marked as "annuling" which pessimizes performance on
all pre-Niagara UltraSparc chips) kills us in things like bench.exe on
Sparc currently.

Also, I cooked up a simple Sparc disassembler which I've integrated
into mono-sparc.c that I'm using to make this work less back-breaking
than it currently is.  In an ideal world, MONO could link to
libopcodes from binutils so that we wouldn't have to do that ugly
"dump into asm file, run objdump on the thing, catch the output" hack
it currently does.  But I don't see that happening any time soon. :-)

With either a libopcodes or by hand assembler, we could stylize the
assembler output, annotating it with MONO CIL opcodes and basic block
information in order to ease the debugging burdon.

Perhaps for the time being we can have some standard interfaces and
some $(cpu)-dis.c source files?  What the current code can do is try
to call the new disassembler interface, and if it returns an error, it
continues on to do the "invoke objdump on foo.s file" thing.

Anyways, just to let folks know what work I have coming down the
pipeline in the not too distant future.

Take care.