This is the mail archive of the
mailing list for the GCC project.
Re: [RFA:] PR55186 - gcc.dg/const-uniq-1.c fails due to vector not in the constant pool
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: ebotcazou at adacore dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 5 Nov 2012 23:23:53 +0100
- Subject: Re: [RFA:] PR55186 - gcc.dg/const-uniq-1.c fails due to vector not in the constant pool
> From: Eric Botcazou <email@example.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
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.