https://issues.dlang.org/show_bug.cgi?id=4231
Andrei Alexandrescu changed:
What|Removed |Added
Version|unspecified |D2
--
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Don changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #15 from Don
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #14 from Don 2010-06-08 04:13:39 PDT ---
(In reply to comment #13)
> Something about that code bugs me, but I'm having trouble deciding exactly
> what
> it is.
>
> Part of it is that there's redundant work. Move the new code insi
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #13 from Brad Roberts 2010-06-08 02:07:14
PDT ---
Something about that code bugs me, but I'm having trouble deciding exactly what
it is.
Part of it is that there's redundant work. Move the new code inside the else
block?
Part of
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #12 from Don 2010-06-08 01:22:02 PDT ---
(In reply to comment #11)
> Hrm.. I haven't studied the side effect code enough. Do you know why
> Comma:Exp::checkSideEffect isn't just:
>
> return e1->checkSideEffect(flag) || e2->checkSi
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #11 from Brad Roberts 2010-06-08 00:24:37
PDT ---
Hrm.. I haven't studied the side effect code enough. Do you know why
Comma:Exp::checkSideEffect isn't just:
return e1->checkSideEffect(flag) || e2->checkSideEffect(flag)
ie, no c
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Don changed:
What|Removed |Added
Keywords||patch
--- Comment #10 from Don 2010-06-08 00:01
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #9 from Don 2010-06-06 13:03:45 PDT ---
Bug 3966 is the same as this one. But I'm loathe to mark either as duplicate
since 4231 contains useful discussions and 3966 has a vote.
--
Configure issuemail: http://d.puremagic.com/issues
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #8 from Brad Roberts 2010-06-02 11:19:00 PDT
---
(In reply to comment #7)
> Inlining is irrelevant. If a this(this) has a writeln() in it, the optimizer
> must honor it no questions asked. That's why elision must come from a higher
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #7 from Andrei Alexandrescu 2010-06-02
10:53:53 PDT ---
(In reply to comment #6)
> I was thinking about the code post-inlining. MOST of the time the operators
> will be inlined and at that point it should be dead simple for it to
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #6 from Brad Roberts 2010-06-02 10:22:56 PDT
---
I was thinking about the code post-inlining. MOST of the time the operators
will be inlined and at that point it should be dead simple for it to eliminate
dead stores and thus the t
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #5 from Andrei Alexandrescu 2010-06-02
08:57:50 PDT ---
That looks like a very specialized optimization to me. In particular, if the
postblit has side effects, the optimizer must have advanced knowledge in order
to elide it. This i
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #4 from Don 2010-06-02 08:53:44 PDT ---
(In reply to comment #2)
> Doesn't the optimizer take care of eliminating the unused temporary and copy?
Good question. Maybe it does. It sees:
auto t = e, foo(e), t;
Does it know in general
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@metalanguage.com
--- Comm
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Brad Roberts changed:
What|Removed |Added
CC||bra...@puremagic.com
--- Comment #2 fro
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Don changed:
What|Removed |Added
Keywords||performance
CC|
17 matches
Mail list logo