Stefan Reinauer stepan@suse.de writes:
Hi,
I'm running out of registers with the Quartet code, I think it's in spd_set_memclk(). That function has quite a lot of state variables, so it seems hard to optimize registers away. The code goes fine without the smbus_write_byte() but those are needed to select the correct spdrom. Is it viable to add a couple of hooks to the code to trigger selection of the hub channel? I guess doing this with every spd_read_byte is quite some overkill and we might save some registers that way.
That sounds like a reasonable idea.
To confirm where you are running out of registers I would suggest commenting out the code in question to see if it compiles without it. Knowing that should help craft a solution.
Depending on the nature of the problem and how we are running out of registers it might make sense to store a couple of values in a single variable.
If you want to keep it from running forever before it gives up I suggest -fmax-allocation-passes=8 -fdebug-live-range-conflicts.
The -fdebug-live-range-conflicts is not terribly interesting except it tells you how many passes romcc goes through before it gives up.
The -fmax-allocation-passes=8 sets the limit on the number of register allocation passes romcc will use. The most I have seen it make and succeed in my regression tests is 6. And the default is 100.
Eric
Grumble, Grumble.
You start running out of registers just when I have figured out how to make inlining functions optional.
I just need to transform my intermediate form from Static Single Assignment, to Continuation passing style. (Basically represent each basic block as a function that preforms a tail call). Doing that I explicitly know which parameters are passed where, and I can explicitly put the registers that are alive across a function call from all of the different call sites in the same variables, which will later wind up in the same registers.
I have an almost usable version that puts all of the different variables that are alive across a call into different registers, which is not very useful.
There is a known issue that some combinations of code that if your present it to the register allocator wrong it fails to allocate registers, as well as the unfortunate fact that register allocator does not always make progress.
I am really hoping you are running into one of those two bugs, as I would like to reduce code space by not inlining everything :)
Of course the great thing about CPS is that it allows the inlining decision to be delayed. So I can be more flexible in that regard. At least I think I can delay it.
The next big step is to properly handle variables that are kept alive across procedure calls and then I can actually get some code compiling and see where I am at.
Eric
-
ebiederman＠lnxi.com