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: [PING^3] Fix reloading of paradoxical subregs into even-only registers


"H.J. Lu" <hjl.tools@gmail.com> writes:
> On Tue, Aug 19, 2008 at 1:33 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>> On Tue, Aug 19, 2008 at 10:13 AM, Michael Matz <matz@suse.de> wrote:
>>>> Hi,
>>>>
>>>> On Tue, 19 Aug 2008, H.J. Lu wrote:
>>>>
>>>>> > +FAIL: gcc.c-torture/compile/pr19357.c  -Os  (test for excess errors)
>>>>
>>>>> > +FAIL: gcc.dg/compat/scalar-by-value-3 c_compat_x_tst.o compile,
>>>>> > (internal compiler error)
>>>>> > +FAIL: gcc.dg/compat/scalar-by-value-6 c_compat_x_tst.o compile,
>>>>> > (internal compiler error)
>>>>> > +FAIL: gcc.dg/compat/scalar-return-3 c_compat_x_tst.o compile,
>>>>> > (internal compiler error)
>>>>> > +FAIL: gcc.dg/compat/struct-by-value-18 c_compat_x_tst.o compile,
>>>>> > (internal compiler error)
>>>>> >
>>>>> > I don't think it is the right fix.
>>>>> >
>>>>>
>>>>> Revert revision 139207 fixes those regressions.
>>>>
>>>> I assumed so.  Before doing a revert and take the less appealing route
>>>> (checking what Richard needs to check _only_ in find_reloads) lets try to
>>>> fix up the ia64 backend some more.  The cause for the above regressions is
>>>> the single only use of gen_rtx_SUBREG in ia64.c, and it's whole purpose is
>>>> to build a subreg so that the called function spill_xfmode_rfmode_operand
>>>> detects the sitation and emits a spill.  But we know exactly what
>>>> situation we are in anyway, and don't need to build "invalid" subregs.
>>>>
>>>> Inlining the call to spill_xfmode_rfmode_operand and simplifying fixes the
>>>> pr19357 FAILs.  Perhaps also the gcc.dg ones.  Attached a new try.
>>>>
>>>>
>>>> Ciao,
>>>> Michael.
>>>> --
>>>>        * ia64/ia64.h (HARD_REGNO_MODE_OK): Use GENERAL_REGNO_P, not
>>>>        GR_REGNO_P.
>>>>        * ia64/ia64.c (ia64_expand_movxf_movrf): Don't generate invalid subregs,
>>>>        inline call to spill_xfmode_rfmode_operand.
>>>>
>>>
>>> I don't feel comfortable to change ia64 backend. Richard had problems
>>> only with paradoxical subregs. But his patch affects ALL subregs. I would
>>> prefer
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01306.html
>>>
>>> which is much less intrusive if it fixes Richard's original problems and
>>> doesn't cause any regressions on ia64.
>>
>> I don't think the msg01306.html patch is the right fix.  Any calculation
>> that relies an invalid reg (in the HARD_REGNO_MODE_OK sense) is inherently
>> flawed.  That's true even if the reg is an intermediate result.
>>
>
> Why is info.representable_p set to true then?

If you're saying that "info.representable_p" is a confusing name,
I certainly wouldn't be averse to changing it.  Can anyone think of
a better name off-hand?

(Your patch also makes subreg_offset_representable_p and
"info.representable_p" different.)

Richard


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