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: Bad choices by expand_mult_highpart

Ulrich Weigand <> writes:
> Do you have any results on whether the code gets in fact better?  You
> avoid the adjustment, but on the other hand you call synth_mult with
> an integer with a lot more 1 bits set; I'm not sure I can easily see
> which one is better.

Me neither.  I was doing this purely on the basis that it's what the old
code did, and that it wasn't something my patch intentionally changed.

However, I tried a few spot checks, and your version does seem to
produce better results in cases where the constant has a repeating
pattern.  For example, on a 64-bit MIPS target, it saves 14 insns on:

    int foo (int x) { return x / -7; }

when compared to the original.  (This was with the multiplication cost
artificially raised so that shifts & adds are always used.)

This suggests there are more things that choose_mult_variant/synth_mult
ought to try, such as getting rid of leading 1s before dealing with the
lower bits.  OTOH, given my recent record, I've very little confidence
I'd get something like that right.

So, patch withdrawn.  I'll try to stop wasting everyone's time
and embarrassing myself further. ;(


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