On 03/15/2017 12:03 AM, Jeff Law wrote:
On 03/10/2017 04:24 PM, Bernd Schmidt wrote:PR rtl-optimization/79910 * combine.c (record_used_regs): New static function. (try_combine): Handle situations where there is an additional instruction between I2 and I3 which needs to have a LOG_LINK updated. PR rtl-optimization/79910 * gcc.dg/torture/pr79910.c: New test.What a nasty little problem. I don't like that we have to build these bitmaps due to the compile-time cost. Would it make sense to only build them when i0/i1 exist?
I suppose at the moment we don't do 2->2 combinations, so we could conditionalize this on having an i1.
We don't do 4->3 combinations, just 4->2 and 3->2, so it's only the i2pattern where we might need to conjure up a LOG_LINK, right? We don't do 4->3 combinations, right? So we only have to care about when there's going to be an newi2pat, right (3->2 or 4->2).
We don't ever create a newi1pat (for a 4->3 combination), right? So we only have to worry about testing when there's a newi2pat, right?
Yes to all, there isn't a newi1pat, only 4->2 and 3->2 can be an issue.
+ if (prev_nonnote_insn (i3) != i2) + for (unsigned r = 0; r < FIRST_PSEUDO_REGISTER; r++) + if (bitmap_bit_p (new_regs_in_i2, r))if (prev_nonnote_insn (i3) != i2 && bitmap_first_set_bit (new_regs_in_i2) < FIRST_PSEUDO_REGISTER)
Ah. I had wondered about the loop but only thought in the direction of intersecting this bitmap with one of all hard regs (and I think there isn't such a bitmap, so I kept the loop). I'll retest with your suggestion and with the bitmap creation conditional on i1 being nonnull.
Bernd
