https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #13 from kugan at gcc dot gnu.org ---
(In reply to avieira from comment #12)
> I heard Kugan was working on getting rid of superfluous zero_extends. Adding
> him to the watch list.
>
> @Kugan: Could your work help this case? And when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #11 from avieira at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #10)
> That is what nonzero_bits etc. is about. We could do much better nowadays
> with the generic DF framework.
>
I am not familiar with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #10 from Segher Boessenkool ---
(In reply to avieira from comment #9)
> > > So I dont know... Only thing I can think of is better "value-range"-like
> > > analysis for combine, but that might be too costly?
That is what nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #9 from avieira at gcc dot gnu.org ---
> > So I dont know... Only thing I can think of is better "value-range"-like
> > analysis for combine, but that might be too costly?
>
> So we are not really looking for combine to combine the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #8 from rguenther at suse dot de ---
On Wed, 7 Sep 2016, avieira at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
>
> --- Comment #7 from avieira at gcc dot gnu.org ---
> if-convert is a no go here,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #7 from avieira at gcc dot gnu.org ---
if-convert is a no go here, for the reason Andrew pointed out, sorry missed
that comment!
So I dont know... Only thing I can think of is better "value-range"-like
analysis for combine, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #6 from avieira at gcc dot gnu.org ---
> so we are talking about the uxthne insn (I don't know arm / thumb very well).
Yes, the uxthne is the "zero_extend" that is otherwise optimized away if you
turn off code-hoisting.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #5 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> It seems with thumb the code is only if-converted after reload for some
> reason.
Most likely because it is going through the cond_exec route.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #4 from Richard Biener ---
Oh, and with -fno-code-hoisting I see
movwr6, #45345
.L5:
smull lr, r4, r5, r1
sub r4, r4, r1, asr #31
add r4, r4, r4, lsl #1
cmp r1, r4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
13 matches
Mail list logo
