https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1dfc50232dcb703454db4f54c538042a32be2138
commit r10-7773-g1dfc50232dcb703454db4f54c538042a32be2138
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #15 from Jeffrey A. Law ---
Comment on attachment 48288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48288
gcc10-pr94567.patch
I think that'll work. If it passes, consider it approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #14 from Jakub Jelinek ---
Created attachment 48288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48288&action=edit
gcc10-pr94567.patch
So perhaps this? In the condition exclude cases where we can't widen the
problematic case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #13 from Jeffrey A. Law ---
Sigh. That code is good in that it's rejecting matching the pattern for the
SImode sign bit that we can't implement. For some dumb reason I was thinking
it was changing how we split, but it's actually th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #12 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #11)
> Rather than extending that hack, I think just widening the mode when the
> sign bit is being tested (c#5) is simpler and easier to understand. The
> bits you'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #11 from Jeffrey A. Law ---
Rather than extending that hack, I think just widening the mode when the sign
bit is being tested (c#5) is simpler and easier to understand. The bits you're
changing should be killed rather than extended t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #10 from Jakub Jelinek ---
So something like:
--- gcc/config/i386/i386.md.jj 2020-03-16 22:56:55.556043275 +0100
+++ gcc/config/i386/i386.md 2020-04-15 19:07:04.405933639 +0200
@@ -8732,8 +8732,20 @@
&& ix86_match_ccmode (ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #8 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #7)
> I think it's trying to use smaller modes because the encodings can be
> smaller. In other cases it changes the mode to avoid partial register
> stalls. It's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #7 from Jeffrey A. Law ---
I think it's trying to use smaller modes because the encodings can be smaller.
In other cases it changes the mode to avoid partial register stalls. It's a
bit of a mess.
WRT the fragment you mentioned, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #6 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #5)
> I've pondered just killing that pattern, but I'm pretty sure there'll be
> notable regressions. There was a clear regression we fixed in gcc-6 due to
> not han
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #5 from Jeffrey A. Law ---
I've pondered just killing that pattern, but I'm pretty sure there'll be
notable regressions. There was a clear regression we fixed in gcc-6 due to not
handling QImode operands in that pattern.
What I'm pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #4 from Richard Biener ---
Wonder if the simplest thing is to turn the zero_extract into a zero_extend
so we can maintain the and in SImode. And whether combine will ever
generate a zero_extract that extracts the SImode MSB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
Component|
15 matches
Mail list logo
