* [Bug c++/45221] missed optimization on casting pointers even under -O3
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
@ 2010-08-07 1:29 ` navin dot kumar at gmail dot com
2010-08-07 1:33 ` [Bug c++/45221] missed optimization with multiple bases and up casting and dereferencing pinskia at gcc dot gnu dot org
` (8 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: navin dot kumar at gmail dot com @ 2010-08-07 1:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from navin dot kumar at gmail dot com 2010-08-07 01:29 -------
The assembly generated for foo1 & foo2 (under -O3) are identical:
leaq -4(%rdi), %rdx
xorl %eax, %eax
testq %rdi, %rdi
cmovne %rdx, %rax
movl 8(%rax), %eax
ret
The assembly generated for foo3 is the most optimal:
movl 4(%rdi), %eax
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and up casting and dereferencing
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
2010-08-07 1:29 ` [Bug c++/45221] " navin dot kumar at gmail dot com
@ 2010-08-07 1:33 ` pinskia at gcc dot gnu dot org
2010-08-07 2:27 ` navin dot kumar at gmail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-08-07 1:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gcc dot gnu dot org 2010-08-07 01:33 -------
Confirmed, the issue has to do with multiple base classes and how NULL pointers
are handled during an upcast.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords| |missed-optimization
Last reconfirmed|0000-00-00 00:00:00 |2010-08-07 01:33:06
date| |
Summary|missed optimization on |missed optimization with
|casting pointers even under |multiple bases and up
|-O3 |casting and dereferencing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and up casting and dereferencing
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
2010-08-07 1:29 ` [Bug c++/45221] " navin dot kumar at gmail dot com
2010-08-07 1:33 ` [Bug c++/45221] missed optimization with multiple bases and up casting and dereferencing pinskia at gcc dot gnu dot org
@ 2010-08-07 2:27 ` navin dot kumar at gmail dot com
2010-08-07 10:37 ` [Bug c++/45221] missed optimization with multiple bases and casting rguenth at gcc dot gnu dot org
` (6 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: navin dot kumar at gmail dot com @ 2010-08-07 2:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from navin dot kumar at gmail dot com 2010-08-07 02:27 -------
The poor optimization does seem to stem from multiple-inheritance (and gcc
trying to preserve nulls across casts). But it's not just upcast; even with
downcasts slow assembly is generated. Take this example:
Base2* fooA(Derived* x)
{
Base2& y = *x;
return &y;
}
Base2* fooB(Derived* x) {
Derived& x2 = *x;
Base2& y = x2;
return &y;
}
Both fooA and fooB are funtionally identical.
Yet the assembly generated for fooA is:
leaq 4(%rdi), %rdx
xorl %eax, %eax
testq %rdi, %rdi
cmovne %rdx, %rax
ret
and the assembly generated for fooB is:
leaq 4(%rdi), %rax
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (2 preceding siblings ...)
2010-08-07 2:27 ` navin dot kumar at gmail dot com
@ 2010-08-07 10:37 ` rguenth at gcc dot gnu dot org
2010-08-07 15:26 ` navin dot kumar at gmail dot com
` (5 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-08-07 10:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-07 10:37 -------
I don't see what the bug is here - this is a feature of the C++ standard,
we can't really "optimize" anything here. 5.2.9/8 ... The null pointer
value is converted to the null pointer value of the destination type.
In the case of foo3 'y' is not a pointer so that special case does not apply.
The only thing we can do is excercise knowledge of undefined behavior as you
dereference the resulting pointer in foo1 and foo2 and thus the behavior
is undefined if that would be a null pointer.
The FE hands us
;; Function int foo2(Base2*) (null)
;; enabled by -tree-original
return <retval> = (x != 0B ? (struct Derived *) x + -4 : 0B)->data;
and we arrive with
<bb 2>:
if (x_2(D) != 0B)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
iftmp.1_3 = x_2(D) + -4;
goto <bb 5>;
<bb 4>:
iftmp.1_4 = 0;
<bb 5>:
# iftmp.1_1 = PHI <iftmp.1_3(3), 0(4)>
D.1726_5 = iftmp.1_1->data;
which we could for example (with -fdelete-null-pointer-checks, where no
objects at address zero can exist), optimize during phiprop if we
insert undefined values as loads from NULL. We could also value-number
loads based on NULL to VN_TOP which would optimize the case during PRE.
Much less fragile is when the code gets inlined into a context where
we know that x isn't a NULL pointer.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (3 preceding siblings ...)
2010-08-07 10:37 ` [Bug c++/45221] missed optimization with multiple bases and casting rguenth at gcc dot gnu dot org
@ 2010-08-07 15:26 ` navin dot kumar at gmail dot com
2010-08-07 16:19 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: navin dot kumar at gmail dot com @ 2010-08-07 15:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from navin dot kumar at gmail dot com 2010-08-07 15:25 -------
Hi Richard,
Your explanation doesn't explain why foo1 would emit poorer assembly than foo3.
Or for that matter why fooA would emit poorer assembly than fooB.
In the case of foo1, foo3, fooA, and fooB, dereferencing occurs first, before
casting. Yet only foo3 and fooB generate optimal assembly (so gcc is clearly
"capable" of outputting the desired asm). This is all at -O3, where
"-fdelete-null-pointer-checks" is already enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (4 preceding siblings ...)
2010-08-07 15:26 ` navin dot kumar at gmail dot com
@ 2010-08-07 16:19 ` rguenth at gcc dot gnu dot org
2010-08-07 16:23 ` navin dot kumar at gmail dot com
` (3 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-08-07 16:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-07 16:19 -------
(In reply to comment #5)
> Hi Richard,
>
> Your explanation doesn't explain why foo1 would emit poorer assembly than foo3.
>
> Or for that matter why fooA would emit poorer assembly than fooB.
>
> In the case of foo1, foo3, fooA, and fooB, dereferencing occurs first, before
> casting. Yet only foo3 and fooB generate optimal assembly (so gcc is clearly
> "capable" of outputting the desired asm). This is all at -O3, where
> "-fdelete-null-pointer-checks" is already enabled.
X* x;
X& = *x;
is not considered a dereference - internally it is just a pointer assignment
we can't derive non-NULL-ness from.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (5 preceding siblings ...)
2010-08-07 16:19 ` rguenth at gcc dot gnu dot org
@ 2010-08-07 16:23 ` navin dot kumar at gmail dot com
2010-08-07 16:25 ` rguenth at gcc dot gnu dot org
` (2 subsequent siblings)
9 siblings, 0 replies; 13+ messages in thread
From: navin dot kumar at gmail dot com @ 2010-08-07 16:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from navin dot kumar at gmail dot com 2010-08-07 16:22 -------
Richard, if you can't derive non-NULL-ness from X& y = *x, how do foo3 and fooB
avoid the null check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (6 preceding siblings ...)
2010-08-07 16:23 ` navin dot kumar at gmail dot com
@ 2010-08-07 16:25 ` rguenth at gcc dot gnu dot org
2010-08-07 16:27 ` rguenth at gcc dot gnu dot org
2010-08-07 17:28 ` navin dot kumar at gmail dot com
9 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-08-07 16:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 16:25 -------
Which means that if the language guarantees that for
Base2* fooA(Derived* x)
{
Base2& y = *x;
return &y;
}
x being a null pointer invokes undefined behavior (because references can't
bind to nothing(?)) then the frontend should emit not
<<cleanup_point struct Base2 & y = (struct Base2 &) (NON_LVALUE_EXPR <x> !=
0B ? &NON_LVALUE_EXPR <x>->D.1702 : 0B);>>;
but instead
<<cleanup_point struct Base2 & y = (struct Base2 &) &NON_LVALUE_EXPR
<x>->D.1702;>>;
CCing Jason.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (7 preceding siblings ...)
2010-08-07 16:25 ` rguenth at gcc dot gnu dot org
@ 2010-08-07 16:27 ` rguenth at gcc dot gnu dot org
2010-08-07 17:28 ` navin dot kumar at gmail dot com
9 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-08-07 16:27 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from rguenth at gcc dot gnu dot org 2010-08-07 16:27 -------
(In reply to comment #7)
> Richard, if you can't derive non-NULL-ness from X& y = *x, how do foo3 and fooB
> avoid the null check?
For both cases the C++ frontend do not emit the NULL check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/45221] missed optimization with multiple bases and casting
2010-08-07 1:28 [Bug c++/45221] New: missed optimization on casting pointers even under -O3 navin dot kumar at gmail dot com
` (8 preceding siblings ...)
2010-08-07 16:27 ` rguenth at gcc dot gnu dot org
@ 2010-08-07 17:28 ` navin dot kumar at gmail dot com
9 siblings, 0 replies; 13+ messages in thread
From: navin dot kumar at gmail dot com @ 2010-08-07 17:28 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from navin dot kumar at gmail dot com 2010-08-07 17:27 -------
Richard, correct references in C++ cannot bind to NULL. So gcc should derive
non-NULL-ness when the argument is a reference. It seems to correctly do this
in the case of foo3 and fooB, but fails to do so for foo1 and fooA.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
^ permalink raw reply [flat|nested] 13+ messages in thread