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]

Re: RFA: enable LRA for rs6000 [patch for WRF]


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


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