On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote: > If I change the above code to > > if (! lra_in_progress && GET_MODE_SIZE (mode) > UNITS_PER_WORD > && !(/* ??? Assume floating point reg based on mode? */ > TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT > && (mode == DFmode || mode == DDmode || mode == > TFmode || mode == TDmode))) > return false; > > the crash is gone.
A lo_sum address isn't always offsettable. You know that you can't read or write the whole TFmode with one instruction, and that the mem will be accessed at addr+0 and addr+8 (and possibly at addr+4 and addr+12). If it so happens that addr is n*65536+32760, then addr+8 will overflow the 16-bit lo_sum and you'll actually try to access n*65536-32768 for the second part. So I don't think your change is correct. > I don't understand what this check means and what comments ??? means too. A lo_sum mem is only valid if you know it won't be offset (or that offsetting will never cross a 64k+32k boundary). If the access is smaller than a word then the load or store can be done in one insn. No offset required. If the access is a DFmode *and* you are loading or storing a floating point reg, then the access is also done in one insn. The ??? comment is referring to the fact that you don't know for sure that the DFmode is in a floating point reg. It usually is, but may be in two general purpose regs. Which then need an offset to load/store the second reg. -- Alan Modra Australia Development Lab, IBM
