> Therefore, I think that the best thing to do is to go back to Uros' original
> idea of distributing the SUBREG only within a PLUS or a MINUS:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01682.html
> The outer operation sort of guarantees that operating in this mode is OK for
> the target, so
Eric Botcazou writes:
> Therefore, I think that the best thing to do is to go back to Uros' original
> idea of distributing the SUBREG only within a PLUS or a MINUS:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01682.html
> The outer operation sort of guarantees that operating in this mode is
> No, the second follow-up was about moving the simplification to combine.c
> and guarding it with !WORD_REGISTER_OPERATIONS, or whatever other check
> you prefer, so that no undoing is necessary.
In fact the mere distribution of the SUBREG seems to be questionable, whatever
the target. For the
Eric Botcazou writes:
>> But that's the problem with trying to do the optimisation in this way.
>> We first simplify a truncation of an SImode addition X. Then we simplify
>> a zero extension of that truncation. Then we have the opportunity to
>> realise that the zero extension wasn't necessary
> But that's the problem with trying to do the optimisation in this way.
> We first simplify a truncation of an SImode addition X. Then we simplify
> a zero extension of that truncation. Then we have the opportunity to
> realise that the zero extension wasn't necessary after all, so we actually
>
On Fri, Dec 6, 2013 at 9:42 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> Well, I think making the simplify-rtx code conditional on the target
>>> would be the wrong way to go. If we really can't live with it being
>>> unconditional then I think we should revert it. But like I say I
Eric Botcazou writes:
>> Well, I think making the simplify-rtx code conditional on the target
>> would be the wrong way to go. If we really can't live with it being
>> unconditional then I think we should revert it. But like I say I think
>> it would be better to make combine recognise the redun
Eric Botcazou writes:
>> The comment says that we're trying to match:
>>
>> 1. (set (reg:SI) (zero_extend:SI (plus:QI (mem:QI) (const_int
>> 2. (set (reg:QI) (plus:QI (mem:QI) (const_int)))
>> 3. (set (reg:QI) (plus:QI (subreg:QI) (const_int)))
>> 4. (set (reg:CC) (compare:CC (subreg:QI) (con
> The comment says that we're trying to match:
>
> 1. (set (reg:SI) (zero_extend:SI (plus:QI (mem:QI) (const_int
> 2. (set (reg:QI) (plus:QI (mem:QI) (const_int)))
> 3. (set (reg:QI) (plus:QI (subreg:QI) (const_int)))
> 4. (set (reg:CC) (compare:CC (subreg:QI) (const_int)))
> 5. (set (reg:CC)
Eric Botcazou writes:
>> Combine is asking simplify-rtx.c to truncate an addition to QImode
>> and simplify-rtx.c is providing a reasonable representation of that.
>> It's the representation we should use when matching against .md patterns,
>> for example. The problem is that combine doesn't want
> Combine is asking simplify-rtx.c to truncate an addition to QImode
> and simplify-rtx.c is providing a reasonable representation of that.
> It's the representation we should use when matching against .md patterns,
> for example. The problem is that combine doesn't want to keep the
> truncation i
Eric Botcazou writes:
>> I don't think this is the way to go. AIUI the problem here isn't that
>> RISC architectures don't have QImode adds as such. If we were going
>> to combine insn 6 and insn 7 _in isolation_ then we would have either:
>>
>>(zero_extend:SI (subreg:QI (plus:SI (subreg:QI
> To me promote_mode sounds like the best fit. But doesn't combine do
> instruction validation? So in this case the target claims to support the
> narrow operation?
Part of the problem is that it's not in the combiner, it's in simplify-rtx.c,
so it's applied liberally when you're manipulating th
> I don't think this is the way to go. AIUI the problem here isn't that
> RISC architectures don't have QImode adds as such. If we were going
> to combine insn 6 and insn 7 _in isolation_ then we would have either:
>
>(zero_extend:SI (subreg:QI (plus:SI (subreg:QI (reg:SI R))
>
Eric Botcazou wrote:
>> For code:
>>
>> unsigned char foo (unsigned char c)
>> {
>>return (c >= '0') && (c <= '9');
>> }
>>
>> we end up generating:
>>
>> sub r0, r0, #48
>> uxtbr0, r0
>> cmp r0, #9
>> movhi r0, #0
>> movls r0, #1
Eric Botcazou writes:
>> For code:
>>
>> unsigned char foo (unsigned char c)
>> {
>>return (c >= '0') && (c <= '9');
>> }
>>
>> we end up generating:
>>
>> sub r0, r0, #48
>> uxtbr0, r0
>> cmp r0, #9
>> movhi r0, #0
>> movls r0, #
> For code:
>
> unsigned char foo (unsigned char c)
> {
>return (c >= '0') && (c <= '9');
> }
>
> we end up generating:
>
> sub r0, r0, #48
> uxtbr0, r0
> cmp r0, #9
> movhi r0, #0
> movls r0, #1
> bx lr
>
> The extr
Hi all,
I'm investigating a testsuite failure on arm: gcc.target/arm/unsigned-extend-1.c
For code:
unsigned char foo (unsigned char c)
{
return (c >= '0') && (c <= '9');
}
we end up generating:
sub r0, r0, #48
uxtbr0, r0
cmp r0, #9
movhi r0, #0
18 matches
Mail list logo
