2011/4/18 Georg-Johann Lay <a...@gjlay.de>: > Denis Chertykov schrieb: >> 2011/4/17 Denis Chertykov <cherty...@gmail.com>: >>> 2011/4/15 Georg-Johann Lay <a...@gjlay.de>: >>>> Finally, I exposed alternative #3 of the insns to the register >>>> allocator, because it is not possible to distinguish between >>>> overlapping or non-overlapping regs, and #3 does not need a scratch. >>>> >>>> Ran C-testsuite with no regressions. >>> Are you encountered any difference in code size ? >> >> I'm ask about code size because the IRA pass isn't work with >> `scratch:MODE' at all. > > I wonder what the difference is; IRA could treat scratch:MODE just the > same way as pseudo:MODE. Anyway, thanks for that insight. It's merely > impossible to get the big picture of IRA/reload from digging sources. > > So that means IRA generates garbage for scratch and reload has to fix > it, generate spill code if needed, etc?
No garbage, IRA just ignore scratch. The reload pass will allocate scratch registers if it's possible. If it's impossible, then reload pass will spill and generate reload for insns with scratches. > Does this mean that if IRA sees a pseudo together with constraint "X" > it will allocate the pseudo, anyway? I think so, but better to test IRA. >> This lead to bad/wrong register allocation in IRA pass. >> The reload pass will correct such a wrong allocation, but reload can't >> generate optimal code. (reload generate correct code). >> Because of that, may be you right and may be better to have >> (clobber (match_operand....)) instead of (clobber (match_scratch...)). > > I don't see effects on code size, at least for the binaries left by > testsuite. > > Is there a policy how to drive size-performance tests for avr? > Anatoly posted a result on code size some weeks ago (concerning move > costs), it would be interesting to know his setup and what > sources/options he uses. Using testsuite seems not appropriate to me, > because it runs -O3, -finline etc. and most code is no real-world > code, at least not for avr. IMHO libgcc is a good test case. > FYI, what I observe is a remarkable dependency on subreg lowering that > can be generalized as this: > * code size decreases for mode <= SImode > * code size increases for mode > SImode I think that DImode move instructions must be supported for representative test results for mode > SImode. Personally I'm don't want to support DImode for AVR. IMHO DImode is an overkill for 8bits controller. Another one note: Few years ago I have played with early splitting of anything possible (move,add,sub,and,...). The results was very bad. It's happened because flow of splitted insns (8bits insns) becomes unreadable for most of GCC optimisation passes. May be splitting is appropriate before register allocation or even after reload pass. Denis. PS: about code size tests: try to email directly to Anatoly. PPS: I can try to call him.
