* [tree-ssa] Simplifying TARGET_EXPR
@ 2002-07-16 9:52 Jason Merrill
0 siblings, 0 replies; 14+ messages in thread
From: Jason Merrill @ 2002-07-16 9:52 UTC (permalink / raw)
To: gcc
Thinking about simplifying TARGET_EXPR, I see two issues to be dealt with:
1) expand_expr's treatment of TARGET_EXPR depends on whether or not it is
being expanded with a target: if so, it initializes the target object;
if not, it initializes a new object. There's no way to model that
behavior with the current simplification code, as there's no concept
of 'target'.
However, I think that the copy-elision should only occur under an
INIT_EXPR, so we can check for TARGET_EXPR in simplify_modify_expr.
This should work fine.
2) Passing a TARGET_EXPR to a call means initializing the temporary on the
stack and passing its address to the call. There's no way to express
this in a simplified form; if we replace the TARGET_EXPR with the
variable it initializes, expand_call will make a bitwise copy, which is
wrong. I can think of two solutions to this:
a) Change expand_call to not copy variables with DECL_ARTIFICIAL set.
b) Pass an ADDR_EXPR of the variable instead, and change expand_call
to handle that case.
My preference is for (b), as (a) might have unintended consequences.
Thoughts?
Jason
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
@ 2002-07-20 18:54 Jason Merrill
2002-07-21 0:41 ` Richard Henderson
2002-07-21 17:32 ` Mark Mitchell
0 siblings, 2 replies; 14+ messages in thread
From: Jason Merrill @ 2002-07-20 18:54 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Richard Henderson, gcc, Jason Merrill
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
I'm interested in what y'all think about the second issue; it's something
I've run into previously when thinking about expanding NEW_EXPR.
One problem with (b) is that using it requires the frontend to know about
passing by invisible reference. However, in the cases where we pass by
invisible reference because TREE_ADDRESSABLE is set on the type, it's
already controlled by the frontend, so that doesn't seem like a big issue.
For cases where we would pass by invisiref for other reasons, doing a
bitwise copy is just inefficient, and we could leave it up to the optimizer
to fix that up.
[-- Attachment #2: Type: message/rfc822, Size: 793 bytes --]
From: Jason Merrill <jason@redhat.com>
To: gcc@gcc.gnu.org
Subject: [tree-ssa] Simplifying TARGET_EXPR
Date: Tue, 16 Jul 2002 11:02:01 +0100
[snip]
2) Passing a TARGET_EXPR to a call means initializing the temporary on the
stack and passing its address to the call. There's no way to express
this in a simplified form; if we replace the TARGET_EXPR with the
variable it initializes, expand_call will make a bitwise copy, which is
wrong. I can think of two solutions to this:
a) Change expand_call to not copy variables with DECL_ARTIFICIAL set.
b) Pass an ADDR_EXPR of the variable instead, and change expand_call
to handle that case.
My preference is for (b), as (a) might have unintended consequences.
Thoughts?
Jason
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-20 18:54 Jason Merrill
@ 2002-07-21 0:41 ` Richard Henderson
2002-07-21 17:32 ` Mark Mitchell
1 sibling, 0 replies; 14+ messages in thread
From: Richard Henderson @ 2002-07-21 0:41 UTC (permalink / raw)
To: Jason Merrill; +Cc: Mark Mitchell, gcc
On Sat, Jul 20, 2002 at 05:09:42PM +0100, Jason Merrill wrote:
> 2) Passing a TARGET_EXPR to a call means initializing the temporary on the
> stack and passing its address to the call. There's no way to express
> this in a simplified form; if we replace the TARGET_EXPR with the
> variable it initializes, expand_call will make a bitwise copy, which is
> wrong. I can think of two solutions to this:
>
> a) Change expand_call to not copy variables with DECL_ARTIFICIAL set.
> b) Pass an ADDR_EXPR of the variable instead, and change expand_call
> to handle that case.
>
> My preference is for (b), as (a) might have unintended consequences.
[...]
> One problem with (b) is that using it requires the frontend to know about
> passing by invisible reference. However, in the cases where we pass by
> invisible reference because TREE_ADDRESSABLE is set on the type, it's
> already controlled by the frontend, so that doesn't seem like a big issue.
> For cases where we would pass by invisiref for other reasons, doing a
> bitwise copy is just inefficient, and we could leave it up to the optimizer
> to fix that up.
(a) is definitely scary.
(b) doesn't seem quite right since the type of the argument doesn't
match up with the type actually passed. Seems like we'd get into
trouble with the backends wrt FUNCTION_ARG et al.
Given that the front end has to know about the semantics of copying
objects and how that affects parameter passing anyway, perhaps the
front end should modify the type of the parameter at the same time.
Perhaps a REFERENCE_TYPE with DECL_ARTIFICIAL set? Then an ADDR_EXPR
would match up nicely.
r~
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-20 18:54 Jason Merrill
2002-07-21 0:41 ` Richard Henderson
@ 2002-07-21 17:32 ` Mark Mitchell
2002-07-21 18:04 ` Gabriel Dos Reis
2002-07-21 22:35 ` Jason Merrill
1 sibling, 2 replies; 14+ messages in thread
From: Mark Mitchell @ 2002-07-21 17:32 UTC (permalink / raw)
To: Jason Merrill; +Cc: Richard Henderson, gcc
--On Saturday, July 20, 2002 05:09:42 PM +0100 Jason Merrill
<jason@redhat.com> wrote:
> I'm interested in what y'all think about the second issue; it's something
> I've run into previously when thinking about expanding NEW_EXPR.
>
> One problem with (b) is that using it requires the frontend to know about
> passing by invisible reference.
I think (b) is by far better than (a).
(What I'd really like to see is the elimination of TARGET_EXPR in the
front end before we reach the optimizers and code generators. This
might miss some opportunities for elimination of copy constructors,
but, in practice, very few. And, to be honest, I'm nervous about the
compiler changing the number of objects constructed and destructed
when optimization is enabled; that makes debugging optimized code
that much harder.)
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-21 17:32 ` Mark Mitchell
@ 2002-07-21 18:04 ` Gabriel Dos Reis
2002-07-21 18:14 ` Mark Mitchell
2002-07-21 22:35 ` Jason Merrill
1 sibling, 1 reply; 14+ messages in thread
From: Gabriel Dos Reis @ 2002-07-21 18:04 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Jason Merrill, Richard Henderson, gcc
Mark Mitchell <mark@codesourcery.com> writes:
| --On Saturday, July 20, 2002 05:09:42 PM +0100 Jason Merrill
| <jason@redhat.com> wrote:
|
| > I'm interested in what y'all think about the second issue; it's something
| > I've run into previously when thinking about expanding NEW_EXPR.
| >
| > One problem with (b) is that using it requires the frontend to know about
| > passing by invisible reference.
|
| I think (b) is by far better than (a).
|
| (What I'd really like to see is the elimination of TARGET_EXPR in the
| front end before we reach the optimizers and code generators. This
| might miss some opportunities for elimination of copy constructors,
| but, in practice, very few. And, to be honest, I'm nervous about the
| compiler changing the number of objects constructed and destructed
| when optimization is enabled; that makes debugging optimized code
| that much harder.)
Do you think we should always elide copy-constructors by default,
unless explicitly told the contrary?
-- Gaby
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-21 18:04 ` Gabriel Dos Reis
@ 2002-07-21 18:14 ` Mark Mitchell
2002-07-21 20:39 ` Gabriel Dos Reis
2002-07-22 12:33 ` Nathan Sidwell
0 siblings, 2 replies; 14+ messages in thread
From: Mark Mitchell @ 2002-07-21 18:14 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Jason Merrill, Richard Henderson, gcc
> Do you think we should always elide copy-constructors by default,
> unless explicitly told the contrary?
Yes.
I think the front end shoul consistently try hard to elide
copy-constructors, then give up and hand off the result to the
optimizers without hoping for any more elision.
Maybe I'm developing an unhealthy paranoia. On the one hand,
optimizing away more copy constructors is like optimizinga away
more copies between scalars, and I'm all for having -O2 do more
of that! On the other, copy constructor elision is observable
behavior in the program, and it's going to make it hard to do
debug, profile, and otherwise analyze your program if the number
of copy constructor calls changes when you optimize.
My two cents,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-21 18:14 ` Mark Mitchell
@ 2002-07-21 20:39 ` Gabriel Dos Reis
2002-07-22 8:32 ` Michael Matz
2002-07-22 12:33 ` Nathan Sidwell
1 sibling, 1 reply; 14+ messages in thread
From: Gabriel Dos Reis @ 2002-07-21 20:39 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Jason Merrill, Richard Henderson, gcc
Mark Mitchell <mark@codesourcery.com> writes:
| > Do you think we should always elide copy-constructors by default,
| > unless explicitly told the contrary?
|
| Yes.
OK, I got it -- I think we're on the same page.
[...]
| On the other, copy constructor elision is observable
| behavior in the program, and it's going to make it hard to do
| debug, profile, and otherwise analyze your program if the number
| of copy constructor calls changes when you optimize.
Since the standard explicitly allows a compiler to elide
copy-constructors even though they have side-effects, C++ proggrammers
have come up (at least there are guidelines to that effect) not to
write programs whose semantics criticall depends on the number of
times copy-constructor/destructor are called.
I'm sympathetic to your take that we should try hard to preserve the
number of copy-constructor calls.
-- Gaby
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-21 20:39 ` Gabriel Dos Reis
@ 2002-07-22 8:32 ` Michael Matz
2002-07-22 12:02 ` Gabriel Dos Reis
2002-07-24 3:22 ` Mark Mitchell
0 siblings, 2 replies; 14+ messages in thread
From: Michael Matz @ 2002-07-22 8:32 UTC (permalink / raw)
To: Mark Mitchell, Gabriel Dos Reis; +Cc: gcc
Hi,
On Sun, 21 Jul 2002, Mark Mitchell wrote:
> > Do you think we should always elide copy-constructors by default,
> > unless explicitly told the contrary?
>
> Yes.
>
> Maybe I'm developing an unhealthy paranoia.
And your coworkers too it seems ;-)
First, I think you meant debugging in general, not specifically with gdb,
didn't you? Because with -O2 programs are not debuggable easily with gdb,
even right now, so gdb-debugging should not be the reason to not elide
copy ctors (or more generally debugging with programs interpreting the
debug info). Then it can only be a form of printf debugging, or asserts.
But e.g. strict aliasing makes such debugging also harder in a similar
way, because valid, but possibly surprising, transformations are made. We
do them anyway, so that also can't be the reason to not elide copy ctors
by default.
So not eliding them should be done only when a switch is given. Maybe
-fno-surprising (which also would switch off other optimizations), or
-fdebug.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-22 8:32 ` Michael Matz
@ 2002-07-22 12:02 ` Gabriel Dos Reis
2002-07-24 3:22 ` Mark Mitchell
1 sibling, 0 replies; 14+ messages in thread
From: Gabriel Dos Reis @ 2002-07-22 12:02 UTC (permalink / raw)
To: Michael Matz; +Cc: Mark Mitchell, aj, gcc
Michael Matz <matz@suse.de> writes:
| Hi,
|
| On Sun, 21 Jul 2002, Mark Mitchell wrote:
|
| > > Do you think we should always elide copy-constructors by default,
| > > unless explicitly told the contrary?
| >
| > Yes.
| >
| > Maybe I'm developing an unhealthy paranoia.
|
| And your coworkers too it seems ;-)
If you have something particular with me, let's take it to private mails.
| First, I think you meant debugging in general, not specifically with gdb,
| didn't you? Because with -O2 programs are not debuggable easily with gdb,
| even right now,
Not just because it is already uneasy means we should make it more
difficult.
| so gdb-debugging should not be the reason to not elide
| copy ctors (or more generally debugging with programs interpreting the
| debug info). Then it can only be a form of printf debugging, or asserts.
Nobody (neither Mark nor me) is proposing not to elide copy
constructors. On the contrary, we're proposing to always elide them
unless explicitly told otherwise.
-- Gaby
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-22 8:32 ` Michael Matz
2002-07-22 12:02 ` Gabriel Dos Reis
@ 2002-07-24 3:22 ` Mark Mitchell
1 sibling, 0 replies; 14+ messages in thread
From: Mark Mitchell @ 2002-07-24 3:22 UTC (permalink / raw)
To: Michael Matz, Gabriel Dos Reis; +Cc: gcc
> But e.g. strict aliasing makes such debugging also harder in a similar
> way, because valid, but possibly surprising, transformations are made. We
> do them anyway, so that also can't be the reason to not elide copy ctors
> by default.
I agree with the antecedent, but not the conclusion. :-)
These are definitly analgous situations, but to me it is a matter of
degree. In other words, the same considerations apply, but in different
proportions, and therefore I reach a different conclusion.
Inserting and removing function calls is -- in my opinion -- a more
significant change in program semantics.
I dn't feel too strongly about this. Maybe I am scarred by having
worked on too many compilers that did this transformation strictly
in the front end.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-21 18:14 ` Mark Mitchell
2002-07-21 20:39 ` Gabriel Dos Reis
@ 2002-07-22 12:33 ` Nathan Sidwell
2002-07-22 12:53 ` Gabriel Dos Reis
2002-07-22 13:10 ` Jason Merrill
1 sibling, 2 replies; 14+ messages in thread
From: Nathan Sidwell @ 2002-07-22 12:33 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Gabriel Dos Reis, Jason Merrill, Richard Henderson, gcc
Mark Mitchell wrote:
> Maybe I'm developing an unhealthy paranoia. On the one hand,
> optimizing away more copy constructors is like optimizinga away
> more copies between scalars, and I'm all for having -O2 do more
> of that! On the other, copy constructor elision is observable
> behavior in the program, and it's going to make it hard to do
> debug, profile, and otherwise analyze your program if the number
> of copy constructor calls changes when you optimize.
I disagree. Alias analysis makes optimized broken programs hard
to debug, I\x13 don't see why temporary elision is any different..
Maybe have the elision separately disablable at -O2, but I think
it should be permissable.
nathan
--
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-22 12:33 ` Nathan Sidwell
@ 2002-07-22 12:53 ` Gabriel Dos Reis
2002-07-22 13:10 ` Jason Merrill
1 sibling, 0 replies; 14+ messages in thread
From: Gabriel Dos Reis @ 2002-07-22 12:53 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Mark Mitchell, Jason Merrill, Richard Henderson, gcc
Nathan Sidwell <nathan@codesourcery.com> writes:
| Maybe have the elision separately disablable at -O2, but I think
| it should be permissable.
I think copy-elision is already controlled by a separate flag.
-- Gaby
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-22 12:33 ` Nathan Sidwell
2002-07-22 12:53 ` Gabriel Dos Reis
@ 2002-07-22 13:10 ` Jason Merrill
1 sibling, 0 replies; 14+ messages in thread
From: Jason Merrill @ 2002-07-22 13:10 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Mark Mitchell, Gabriel Dos Reis, Richard Henderson, gcc
>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:
> Mark Mitchell wrote:
>> Maybe I'm developing an unhealthy paranoia. On the one hand,
>> optimizing away more copy constructors is like optimizing away
>> more copies between scalars, and I'm all for having -O2 do more
>> of that! On the other, copy constructor elision is observable
>> behavior in the program, and it's going to make it hard to do
>> debug, profile, and otherwise analyze your program if the number
>> of copy constructor calls changes when you optimize.
> I disagree. Alias analysis makes optimized broken programs hard
> to debug, I don't see why temporary elision is any different..
> Maybe have the elision separately disablable at -O2, but I think
> it should be permissable.
I agree. Copy constructor calls are small change in debuggability of
optimized code.
Of course, we've never tried to optimize away more copy constructors after
inlining, so this is all theoretical...
Jason
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [tree-ssa] Simplifying TARGET_EXPR
2002-07-21 17:32 ` Mark Mitchell
2002-07-21 18:04 ` Gabriel Dos Reis
@ 2002-07-21 22:35 ` Jason Merrill
1 sibling, 0 replies; 14+ messages in thread
From: Jason Merrill @ 2002-07-21 22:35 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Richard Henderson, gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
> (What I'd really like to see is the elimination of TARGET_EXPR in the
> front end before we reach the optimizers and code generators.
Yep, that's what I have in mind.
Jason
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-07-24 2:07 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-16 9:52 [tree-ssa] Simplifying TARGET_EXPR Jason Merrill
2002-07-20 18:54 Jason Merrill
2002-07-21 0:41 ` Richard Henderson
2002-07-21 17:32 ` Mark Mitchell
2002-07-21 18:04 ` Gabriel Dos Reis
2002-07-21 18:14 ` Mark Mitchell
2002-07-21 20:39 ` Gabriel Dos Reis
2002-07-22 8:32 ` Michael Matz
2002-07-22 12:02 ` Gabriel Dos Reis
2002-07-24 3:22 ` Mark Mitchell
2002-07-22 12:33 ` Nathan Sidwell
2002-07-22 12:53 ` Gabriel Dos Reis
2002-07-22 13:10 ` Jason Merrill
2002-07-21 22:35 ` Jason Merrill
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).