This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
On 12/09/14 12:21, Wilco Dijkstra wrote:
But there are other times when you really don't want to copy, say when the original had a small class, but the copy can go into a larger class.This fixes a bug in register preferencing. When live range splitting creates a new register from another, it copies most fields except for the register preferences. The preference GENERAL_REGS is used as reg_pref[i].prefclass is initialized with GENERAL_REGS in allocate_reg_info () and resize_reg_info (). This initialization value is not innocuous like the comment suggests - if a new register has a non-integer mode, it is forced to prefer GENERAL_REGS. This changes the register costs in pass 2 so that they are incorrect. As a result the liverange is either spilled or allocated to an integer register: void g(double); void f(double x) { if (x == 0) return; g (x); g (x); } f: fcmp d0, #0.0 bne .L6 ret .L6: stp x19, x30, [sp, -16]! fmov x19, d0 bl g fmov d0, x19 ldp x19, x30, [sp], 16 b g With the fix it uses a floating point register as expected. Given a similar issue in https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html, would it not be better to change the initialization values of reg_pref to illegal register classes so this kind of issue can be trivially found with an assert? Also would it not be a good idea to have a single register copy function that ensures all data is copied?
I banged my head on this when I was doing similar work on range splitting a few years back and ended up recomputing the preferred and alternate class information. That was much better than copying the classes.
I pondered heuristics to expand the preferred class, but never implemented anything IIRC. A trivial heuristic would be to bump to the next larger class if the given class was a singleton, otherwise copy the class.
The obvious counter to that heuristic is an allocno that has two ranges (or N ranges) where we would prefer a different singleton class for each range. In fact, I'm pretty sure I ran into this kind of situation and that led me down the "just recompute it" path.
I'd hazard a guess that the simple heuristic would do better than what we're doing now with GENERAL_REGS though or what you're doing with copying.
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |