Denis Chertykov schrieb: > 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.
I don't see differences there, either. This is presumably because rotate pattern is not used resp. used only very seldom. >> 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. Some people use 64bit on AVR. But to support a movdi would be very painful, I think it would cause more harm like spill failures than good. > 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. The -f[no-]split-wide-types happens before reload, in .subreg1 (prior to combine) resp. .subreg2 (after combine). For 64bit, without subreg lowering, there is an insn like (clobber (reg:DI 43 [ <retval> ])) which causes bunch of moves and finally the setup of a frame pointer even though nothing lives in the frame. How can add, sub etc. be split? This would need an explicit representation of carry. > Denis. > PS: about code size tests: try to email directly to Anatoly. > PPS: I can try to call him. Johann
