> From: Eric Botcazou <ebotca...@adacore.com> > Date: Mon, 5 Nov 2012 15:29:11 +0100
> > But, for cris-elf (and reasonably the same for other targets) > > there might not be such a constant-pool entry in the first > > place: the vectors are too short to rule out piecewise > > initialization as optimal for size (counting the vectors once > > per use). Let's increase them. Twice might just break-even for > > cris-elf so let's make them four times as long. Sanity-checked > > for x86_64 w/w.o -m32 for a gcc-version that includes the > > optimization for which the test-case tests (CCing author). > > I don't know cris at all, but 4 times sounds quite a lot compared to the > other > architectures (I presume that the test passes on most of them). That's right, because I *want* the size to be excessive compared to the (expected max) in-line-limits of any target. What I wrote above regarding numbers is incorrect; i misthought. Counting just the size of the vector and emitted instructions, it wouldn't make sense to just increase the vector, as the size for the best-case instructions for initializing one item in the 32-bit-int: moveq 1,$r2 move.d $r2,[$r10+] is four bytes; the size the corresponding constant-vector item. The overhead for forming the address in a register is of course smaller than the overhead for calling memcpy, as the former is a subset of the latter. :) What happens is that I increase the vector-length much above what I see as the expected target-specific max-limit for the in-lined memcpy/memset/whatever; from 32 to 128 for 32-bit targets. Yes, outliers are expected to have to adjust the test-case anyway; this outlier is just the first one, I'm vainly hoping there will be no others. :) I could also have just changed the numbers in the vector from those expected to be quickly formed (for CRIS, 0..31) to e.g. random numbers, but then I'd have to deal with 32-bit vs. 16-bit-issues ...and also, to be absolutely correct I'd have to deal with issues where the size of the emitted in-lined code isn't fit for -Os compared to memcpy. IIRC when -Os, gcc middle-end *doesn't* emit rtl and add the sizes of the insns (the insn attribute-size numbers) before deciding on emitting insns or in-lined memcpy. I *guess* the 32 bytes set [for CRIS] by MOVE_RATIO is the only target-number that matters at present. Since this minor can of worms wasn't the point of this test-case, I opted for simply increasing the size of the vector, keeping it simple. > No objections by me though. I take that as approval. Committed as posted. brgds, H-P
