Guillermo Adrián Molina writes:
If you want to fix that limit in the register allocator I could give you some pointers. The problem is due to to how the problem is broken down into stages. I'd need to dig through code to remember the
details
though.
Yes I do want. Please let me know where to start.
If it's not an urgent problem then it may be better to wait until after 0.13. Or to look at the register allocator during 0.13 development.
Have a look at the stages of simplification. They're done
ColouringRegisterAllocator>>processWorkLists simplifyWorklist isEmpty ifFalse: [^ self simplify]. self coalesce ifTrue: [^ self]. self freeze ifTrue: [^ self]. spillWorklist isEmpty ifFalse: [^ self spillRegister]. self spillMove
Sets the steps for processing. However the spill worklist has some registers on it that shouldn't be spilled, so it tries to select a register to spill. It discards all registers then fails.
I'd see if there are any moves that might be spilled afterwards, if so, then all you'd need to do is allow spillRegister to fail gracefully.
Ok, I will try to see what is happening. Is there any hard limit (besides the number of available registers in x86 arch)?
I'm planning on working on the register allocator in the next
release.
The goal will be making it faster, it has a few serious performance problems.
Exupery's compile time is not a problem for me. But may be I have to
wait
for you to finish with the register allocator, in order to try to fix
the
limit. Please let me know what do you want me to do. Right now, I have allready finished with unit testing. The next thing I will do is to include all the compiler classes in my project (remeber
tat
right now, that is done in Squeak), may be it would be convenient for
me
to wait for 0.12 before I do that.
Another thing, Do you want the code I made for cmovxx?
I'm interested.
Does it have unit test coverage? Exupery development relies on testing so that's required.
Not right now, I will work on that later, When I have it I will send it to you.
When was cmov introduced? I know it was a long time ago but can't remember precisely when. What I'm concerned with is making Exupery incompatable with some chips that might still be being used.
Intel's optimization manual says that cmov was introduced in Pentium, and in AMD's optimization manual says that cmov is available from athlon. I actually didn't investigate that thoroughly. The fact is that any modern computer should have it. I know that in earlier implementations of cmov (Pentium Pro) using the instruction wasn't really an advantage. But now, it is really faster. My tinyBenchamrks showed a speed up of 10% when I implemented cmov for smallinteger additions. But, If you are really concerned about compatibility I think you should be better considering not to use it.
Given adequate test coverage I'll add it.
I also implemented enter and leave instructions. Not because they were better (they aren't), but, beacuse I use it to signal the inclusion of additional prologue and epilogue code in a final phase added just after the allocator. I do it that way because I dont know until then, which registrs are used, and the number of additional temps needed. I know that exupery allways push and pop all the registers (which aren't eax, edx and ecx). And that it make place for a big context as temp space in stack. I don't do that. I only push the used regs, and if that is not enough, I enter additional stack space. That brakes compatibility with original exupery, but I wanted to implement it that way. For small methods, that is really better. So, given that, I don't offer anything of this for you. I think you'll understand.
Cheers, Guille
Bryce _______________________________________________ Exupery mailing list Exupery@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery