This is the mail archive of the gcc-bugs@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]

[Bug target/81357] Extra mov for zero extend of add


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357

--- Comment #5 from Qing Zhao <qing.zhao at oracle dot com> ---
Hi, wilco,

thanks for the comments.
see me reply below:

> On Sep 28, 2017, at 2:13 PM, wilco at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
> 
> --- Comment #4 from Wilco <wilco at gcc dot gnu.org> ---
> (In reply to Qing Zhao from comment #3)
>> 1. the zero extension comes from the language standard naturally. for
>> aarch64, due to the fact that the register W0 to X0 implicitly zero
>> extension, the explicitly zero extension insn can be optimized by some
>> peephole optimization I think.
>> 
>> 2. will study why insn scheduler introduced the additional mov insns.
> 
> The scheduler didn't introduce an additional move. There are 2 distinct values
> here, the 32-bit value fParm + 1 and the 64-bit zero-extended version of it.
> Your example shows it perfectly:
> 
>        add     w1, w0, 1
>        mov     w0, w1
>        uxtw    x1, w1
> 
> The mov and uxtw are in fact the same instruction, however they are different
> in the intermediate code. Due to being different operations the register
> allocator needs 2 registers.

don’t quite understand your above. what’s your mean by “the mov and uxtw are in
fact the same instruction”?

from my understanding:

the “mov” insn that is added by -O2 is mainly for returning an unsigned int 
from the function. since by ABI, the register
w0 should hold the result that will be return. 

at the same time, the “uxtw” insn is there because of the explicitly conversion
from “unsigned int to unsigned long long”. 

If the first “add” insn keeps as “W0” as the destination (i.e. add w0, w0,1),
then the “mov” insn is NOT needed at all.

Not sure why when -fschedule-insns is ON, the destination of the add insns
becomes W1?

Qing



> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.

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