This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING: PR/17236, improve long long multiply on x86 (middle-end)

That said, I wonder if it might actually make sense (no, I didn't
think it that way, but I ask) if we do this change only in

I think you need to make an argument for why that would be better.

Because local-alloc.c only allocates registers with a relatively short live range, and bumping the priority of smaller register classes would be less disrupting.

I'm OK with making this sort of change without a clear argument, but
only if you're prepared to do performance testing on three or more
primary platforms.  I'm not OK with making this sort of change with
neither an argument nor performance testing.  Right now, as far as I
know, you just have a single test case which improves.

I already had SPEC on x86 and it was neutral, except that half of SPECfp was perturbated by the machine load. I should be able to rerun it sometime next week. Running i386 and x86_64 would not be very different (the RA problems are the same -- %eax/%edx for MUL/DIV and %cl for shift counts) and I don't have access to other platforms.

So, I will try to audit other back-ends like I did for MIPS. Before that, I will see what IRA does; maybe we don't need at all the patch.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]