public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/95891] New: Missing optimization
@ 2020-06-25 8:38 jm at bourguet dot org
2020-06-25 11:09 ` [Bug rtl-optimization/95891] " rguenth at gcc dot gnu.org
2021-05-30 23:26 ` [Bug tree-optimization/95891] " pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: jm at bourguet dot org @ 2020-06-25 8:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95891
Bug ID: 95891
Summary: Missing optimization
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jm at bourguet dot org
Target Milestone: ---
I'm sorry, this is perhaps not the correct component but my knowledge of gcc
internals does not allow me to do more than guess.
For all version of gcc I've tried, the following code:
struct point {
int x, y;
};
bool f(point a, point b) {
return a.x == b.x && a.y == b.y;
}
bool f(unsigned long long a, unsigned long long b) {
return a == b;
}
is compiled to
f(point, point):
xor eax, eax
cmp edi, esi
je .L5
ret
.L5:
sar rdi, 32
sar rsi, 32
cmp edi, esi
sete al
ret
f(unsigned long long, unsigned long long):
cmp rdi, rsi
sete al
ret
I'd expect f(point, point) to have the same assembly as f(unsigned long long,
unsigned long long).
Yours,
-- Jean-Marc Bourguet
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/95891] Missing optimization
2020-06-25 8:38 [Bug rtl-optimization/95891] New: Missing optimization jm at bourguet dot org
@ 2020-06-25 11:09 ` rguenth at gcc dot gnu.org
2021-05-30 23:26 ` [Bug tree-optimization/95891] " pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-06-25 11:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95891
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Ever confirmed|0 |1
Last reconfirmed| |2020-06-25
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug tree-optimization/95891] Missing optimization
2020-06-25 8:38 [Bug rtl-optimization/95891] New: Missing optimization jm at bourguet dot org
2020-06-25 11:09 ` [Bug rtl-optimization/95891] " rguenth at gcc dot gnu.org
@ 2021-05-30 23:26 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-05-30 23:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95891
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Component|rtl-optimization |tree-optimization
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. Happens on aarch64 too:
cmp w0, w1
beq .L5
mov w0, 0
ret
.p2align 2,,3
.L5:
asr x0, x0, 32
asr x1, x1, 32
cmp w0, w1
cset w0, eq
ret
I wonder if we could expose that point is passed via a 64bit argument at the
tree level and then use BIT_FIELD_REF to do the extraction or lower the field
extractions to BIT_FIELD_REF.
Also we don't optimize:
bool f1(unsigned long long a, unsigned long long b) {
return (((int)a) == ((int)b)) && ((int)(a>>32) == (int)(b>>32));
}
into just return a==b; either.
Which is another thing which needs to happen after the BIT_FIELD_REF Change ...
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-05-30 23:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-25 8:38 [Bug rtl-optimization/95891] New: Missing optimization jm at bourguet dot org
2020-06-25 11:09 ` [Bug rtl-optimization/95891] " rguenth at gcc dot gnu.org
2021-05-30 23:26 ` [Bug tree-optimization/95891] " pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).