https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #14 from Roger Sayle ---
Created attachment 54197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54197=edit
Related optimizations to ix86_expand_int_movcc.
Just for the record, here is a related patch that I was working on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #13 from H.J. Lu ---
I also got
$ cat foo.i
extern void foo (float *);
extern int x;
int
mouse_frame_side(void) {
float mouseloc;
foo ();
return mouseloc > x ? 1 : 2;
}
$ gcc -march=alderlake -Ofast -S foo.i
during RTL pass:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #12 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:9e6ac747ac5cff9e3f58421cdd9f03538e48ed07
commit r13-5038-g9e6ac747ac5cff9e3f58421cdd9f03538e48ed07
Author: Roger Sayle
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Roger Sayle from comment #8)
> > Here's my proposed patch (or something close to it, it's still bootstrapping
> > and regression testing). The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #10 from Jakub Jelinek ---
(In reply to Roger Sayle from comment #8)
> Created attachment 54195 [details]
> Roger's proposed patch
>
> Here's my proposed patch (or something close to it, it's still bootstrapping
> and regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #9 from Roger Sayle ---
Another way to avoid the SCALAR_FLOAT_MODE_P problem is:
/* Add a REG_EQUAL note to allow condition to be shared. */
rtx note = gen_rtx_fmt_ee (orig_code, mode, op0, op1);
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #8 from Roger Sayle ---
Created attachment 54195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54195=edit
Roger's proposed patch
Here's my proposed patch (or something close to it, it's still bootstrapping
and regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #7 from Jakub Jelinek ---
Or for now don't add any REG_EQUAL note if op0 has scalar floating point
mode...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #6 from Jakub Jelinek ---
So I wonder about:
--- gcc/config/i386/i386-expand.cc.jj 2023-01-04 10:45:49.978883731 +0100
+++ gcc/config/i386/i386-expand.cc 2023-01-05 18:22:40.228518935 +0100
@@ -3271,10 +3271,12 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #5 from Jakub Jelinek ---
Though, it seems the REG_EQUAL note is also wrong on the cmov10.c testcase
which went with the commit (again, exact opposite).
Seems we have multiple cases where this REG_EQUAL note is newly added.
One is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #2 from Jakub Jelinek ---
The assembly difference is
- movl$1, x+20(%rip)
+ movl$-6, x+20(%rip)
Now, that is the correct value to be stored into x[5] by the
__builtin_sub_overflow (0, 6, [5]);
statement, but each
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
17 matches
Mail list logo
