On Mon, Dec 15, 2014 at 10:24:47AM -0600, Segher Boessenkool wrote:
> On Mon, Dec 15, 2014 at 04:51:14PM +0100, Paolo Bonzini wrote:
> > 1) did you check that it never triggers on e.g. an x86 bootstrap, and
> > that it doesn't trigger too often on PPC64?
>
> I have checked on my largish connection of tests for the carry insns
> on PowerPC, and only two (related) transforms are disabled, and they
> aren't too important anyway. Well, and the bad transforms are disabled,
> only just two of-em but much more frequent (long long x; x--;).
>
> I haven't checked on x86, but it's a bugfix: don't do things that blow up!
> It is amazing to me that it didn't show up before. One theory is that
> instructions that set the condition code as well as a GPR will never
> combine with a later insn to two insns, always to just one. But nothing
> made this explicit so AFAICS it is just an accident that it worked before.
>
> I'll do an instrumented x86 bootstrap.
I did a run for powerpc64, one for powerpc, and one for x86-64.
The powerpc64 bootstrap was with pre-installed GMP etc.; the others
had those libraries in-tree.
"type1" is when try_combine used the ancient combine code to split a
parallel set and set of cc; "type2" is when it used my code to split
any other parallel that sets two things; and "type0" is when it didn't
do either but still ended up with I1 and I2 the same UID (I think it
might be called with the same insn twice; not a good thing, it does
not know how to handle this; and it is really worrisome that it then
sometimes succeeds in combining it).
"tries" is how often that split-orig-I2-to-two code is used; "recog"
is how often it reached the first call to recog (so it passed
can_combine_p etc.); "fail" is how often it eventually failed (after
reaching recog), "one" is how often it combined to one insn, "two"
is how often it combined to two.
powerpc64
tries recog fail one two
type1 39214 39214 38944 202 18
type2 21540 18968 18928 2 38
type0 292 289 0 3
powerpc
tries recog fail one two
type1 21654 21654 21167 485 2
type2 21839 19754 19243 0 509 (*)
type0 427 294 0 133
x86-64
tries recog fail one two
type1 17387 17387 17288 70 29
type2 40413 31681 30242 60 1369
type0 0 0 0 0
Not sure what to make of the high number in the x86-64 type2/two
result.
Segher
(*) The (32-bit) powerpc bootstrap failed (that's what the patch
is trying to rectify, after all); the columns on this line don't
add up correctly (two are missing; this was a -j60 build).
