https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #13 from Qing Zhao ---
I checked the same testing case on X86, SPARC in addition to aarch64, all have
the same issue: (compile with gcc -O, the default is -m64)
***x86:
test1:
.LFB0:
.cfi_startproc
leal1(%rdi), %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #12 from Qing Zhao ---
> Well it is not wrong, just non-optimal. It is possible to use a single
> register
> here but it means teaching GCC that these values are identical, which is
> non-trivial as it likely affects various places i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #11 from Wilco ---
(In reply to Qing Zhao from comment #10)
> the following is my conclusion on this bug based on previous discussion and
> study, for this testing case:
>
> 1. due to the fact that "mov" and "uxtw" are the same in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #10 from Qing Zhao ---
the following is my conclusion on this bug based on previous discussion and
study, for this testing case:
1. due to the fact that "mov" and "uxtw" are the same instruction, the
assembly generated by -O1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #9 from Andrew Pinski ---
(In reply to Qing Zhao from comment #8)
> >
> > I don't think there is an easy fix for this example. The compiler believes
> > there are 2 distinct values so it uses 2 registers irrespectively of the
> > or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #8 from Qing Zhao ---
>
> I don't think there is an easy fix for this example. The compiler believes
> there are 2 distinct values so it uses 2 registers irrespectively of the order
> of the mov and uxtw.
then, why when there is NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #7 from Wilc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #6 from Andrew Pinski ---
(In reply to Qing Zhao from comment #5)
>
> don’t quite understand your above. what’s your mean by “the mov and uxtw are
> in fact the same instruction”?
In aarch64 assembly mov and uxtw are alias of each o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #5 from Qing Zhao ---
Hi, wilco,
thanks for the comments.
see me reply below:
> On Sep 28, 2017, at 2:13 PM, wilco at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
>
> --- Comment #4 from Wilco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #4 from Wilco ---
(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 e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|qing.zhao at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #3 from Qing Zhao ---
the zero extension "uxtw" insn is generated even without any optimiation, the
additional "mov" insn generated in -O2 is introduced by -fschedule-insns,
please see the following:
***/home/qinzhao/Install/latest/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
--- Comment #2 from Andrew Pinski ---
-O1 produces an extra zero extend.
-O2 and above produces an extra move instruction.
The zero extend is not needed as the add does an implicit zero extend already.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
Qing Zhao changed:
What|Removed |Added
CC||qing.zhao at oracle dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
16 matches
Mail list logo
