This is the mail archive of the gcc@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: Truncate optimisation question


> For code:
> 
> unsigned char foo (unsigned char c)
> {
>    return (c >= '0') && (c <= '9');
> }
> 
> we end up generating:
> 
>          sub     r0, r0, #48
>          uxtb    r0, r0
>          cmp     r0, #9
>          movhi   r0, #0
>          movls   r0, #1
>          bx      lr
> 
> The extra uxtb (extend) is causing the test to fail. We started generating
> the extra extend when a particular optimisation went in with (revision
> r191928).

That's PR rtl-optimization/58295.  We have pessimizations on the SPARC too.

> The comment in simplify-rtx.c says it transforms
> (truncate:SI (op:DI (x:DI) (y:DI)))
> 
> into
> 
> (op:SI (truncate:SI (x:DI)) (truncate:SI (x:DI)))
> 
> but from what I can see it also transforms
> 
> (truncate:QI (op:SI (x:SI) (y:SI)))
> 
> into
> 
> (op:QI (truncate:QI (x:SI)) (truncate:QI (x:SI)))
> 
>  From the combine dump I see that the sub and extend operations come from
> the RTL:
> 
> (insn 6 3 7 2 (set (reg:SI 116)
>          (plus:SI (reg:SI 0 r0 [ c ])
>              (const_int -48 [0xffffffffffffffd0])))
> 
> (insn 7 6 8 2 (set (reg:SI 117)
>          (zero_extend:SI (subreg:QI (reg:SI 116) 0)))
> 
> 
> If I add a QImode compare pattern to the arm backend it gets matched and the
> extra extend goes away, but it seems to me that that's not the correct
> solution. Ideally, if a QImode operation is performed as an SImode
> operation on a target (like the sub and compare operations on arm) then we
> should not be doing this optimisation?

Yes, that's my opinion as well, but Richard (CCed) seemed to disagree.  In any 
case, that's certainly not a simplification.

> My question is, how does one express that information in the simplify-rtx.c
> code? It seems that the PR that optimisation fixed (54457) only cared about
> DI -> SI truncations, so perhaps we should disable it for conversions
> between other modes where it's not beneficial altogether?

I can think of 3 possible solutions:
 - WORD_REGISTER_OPERATIONS,
 - promote_mode,
 - optabs.

The 3rd solution seems to be the most straightforward, but this would be the 
first time that we test optabs from simplify-rtx.c.

-- 
Eric Botcazou


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