"David Edelsohn" <[EMAIL PROTECTED]> writes:
> On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
> <[EMAIL PROTECTED]> wrote:
>>> I agree. So your plan would be to change rs6000 to an unspec, and drop
>>> the problematic hunk in simplify-rtx.c? That would be okay with me, but
>>> it's not a small
On Sun, Sep 7, 2008 at 1:58 PM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
>> I agree. So your plan would be to change rs6000 to an unspec, and drop
>> the problematic hunk in simplify-rtx.c? That would be okay with me, but
>> it's not a small change for rs6000.
>
> Yeah, this is very much my p
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> would in some cases be accurate.) I think using an unspec in rs6000
>> would solve some of the port-specific issues. In particular, I don't
>> think 36090 would have happened with an unspec representation.
>
> I agree. So your plan would be to change
> Date: Sun, 07 Sep 2008 17:48:17 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > 3. Change the default of LEGITIMATE_CONSTANT_P to a helper
> >function, maybe trivial_constant_expression_p above.
>
> Agreed, but I don't see t_c_e_p in GCC sources
Of course not, as it's a *proposed* new
> Only with a LEGITIMATE_CONSTANT_P catching it...
Of course.
> So, can we agree on some or all of:
>
> 1. This (PR37363/PR36182) and PR36090 (in both ports) and
>whatever other port will be affected should be solved by a
>stricter LEGITIMATE_CONSTANT_P check, and where
>canonicaliz
> Date: Sat, 06 Sep 2008 15:14:46 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> >> H-P can check for the problematic case inside his LEGITIMATE_CONSTANT_P
> >> (*), or add a move expander for it.
> >
> > I think you're mixing up CRIS and rs6000, the latter which
> > generated something it had
> As H-P says, the predicates on move expanders are generally ignored.
> emit_move_insn & subroutines deliberately don't check them.
It's even worse; force_reg is effectively hardcoding movXX's operand 1
to be a general_operand. (But my point was that force_reg does use
LEGITIMATE_CONSTANT_P thr
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>>> In case of cris, the predicate goes into general_operand, which does
>>>
>>> if (CONSTANT_P (op))
>>> return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
>>> || mode == VOIDmode)
>>> && (! flag_pic || LEGITIMATE_PI
>> In case of cris, the predicate goes into general_operand, which does
>>
>> if (CONSTANT_P (op))
>> return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
>> || mode == VOIDmode)
>> && (! flag_pic || LEGITIMATE_PIC_OPERAND_P (op))
>> && LEGITIMATE_
> Date: Sat, 06 Sep 2008 12:50:18 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> Still, having a new target hook for this seems overkill.
But it's better than abusing an old macro with a slightly
different use.
> For example,
> since ports do have to deal with complicated constants when they
> if plus_constant _knows_ that something can be wrapped in a CONST,
> simplify_binary_operation should have given us the CONST to begin with.
> Also, the only cases that plus_constant can handle are CONST,
> SYMBOL_REF and LABEL_REF, all of which satisfy CONSTANT_P.
> So the new form ought to be
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> I'm not sure about this bit. Couldn't [snip cse.c code]
>> simply be replaced by:
>>
>> /* We can't simplify extension ops unless we know the
>> original mode. */
>> if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
>>&& mode_a
> I'm not sure about this bit. Couldn't [snip cse.c code]
> simply be replaced by:
>
> /* We can't simplify extension ops unless we know the
>original mode. */
> if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
> && mode_arg0 == VOIDmode)
> break;
>
> new
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Index: cse.c
> ===
> --- cse.c (revision 134435)
> +++ cse.c (working copy)
> @@ -3161,10 +3161,8 @@ fold_rtx (rtx x, rtx insn)
> FIXME: those ports should be fixed. */
>
Paolo Bonzini wrote:
> Hans-Peter Nilsson wrote:
>>> Date: Fri, 5 Sep 2008 14:57:00 +0200
>>> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
>>> Maybe as part of a change from target macro to target hook, with
>>> LEGITIMATE_CONSTANT_P as a default would fit, even at this
>>> stage?
>> Sorry, I mean
Hans-Peter Nilsson wrote:
>> Date: Fri, 5 Sep 2008 14:57:00 +0200
>> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
>
>> Maybe as part of a change from target macro to target hook, with
>> LEGITIMATE_CONSTANT_P as a default would fit, even at this
>> stage?
>
> Sorry, I mean CONSTANT_P, not LEGITIM
> Date: Fri, 5 Sep 2008 14:57:00 +0200
> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
> Maybe as part of a change from target macro to target hook, with
> LEGITIMATE_CONSTANT_P as a default would fit, even at this
> stage?
Sorry, I mean CONSTANT_P, not LEGITIMATE_CONSTANT_P. Or maybe a
new macro
> Date: Fri, 05 Sep 2008 14:42:11 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> We can do it incrementally. For now, only redefine
> LEGITIMATE_CONSTANT_P on CRIS and in the documentation, and use it in
> simplify_plus_minus. For 4.5, we can look at other places using
> gen_rtx_CONST and str
>> 3) adding a check that the MINUS is a legitimate address, and only wrap
>> it in CONST if it is.
>
> s/address/constant/; it's not clear that it's used as an address
> at that point; it's just two expressions that gcc tries to
> reduce.
Right.
> But I get the point; I'm leaning towards somet
On Fri, Sep 5, 2008 at 7:25 AM, Hans-Peter Nilsson
<[EMAIL PROTECTED]> wrote:
>> Date: Fri, 05 Sep 2008 12:55:17 +0200
>> From: Paolo Bonzini <[EMAIL PROTECTED]>
> Nope, not if it's a (MINUS (symbol_ref sym2) (symbol_ref sym1)).
> *If* valid, that's a constant expression and *should* be wrapped
>
> Date: Fri, 05 Sep 2008 12:55:17 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > I got negative feedback on that patch (no, not regression
> > results :) on IRC from David Edelsohn and understandably you
> > held off your testing because of this, as for one the patch
> > affects the rs6000 ba
> I got negative feedback on that patch (no, not regression
> results :) on IRC from David Edelsohn and understandably you
> held off your testing because of this, as for one the patch
> affects the rs6000 backend.
What kind of negative feedback?
> For CRIS (as well as other targets IIUC) the ca
22 matches
Mail list logo
