On Wed, May 4, 2011 at 7:14 PM, Eric Botcazou ebotca...@adacore.com wrote:
Actually it turns out that it doesn't matter. If we arrive here with
something that needs a SAVE_EXPR we have to be able to generate code
for it somewhere, where there would be obviously the possibility to
also
Sure, but that's a limitation of out SAVE_EXPR handling (given that it
would be ok to expand the SAVE_EXPR multiple times - once per
instantiation context).
You need to expand the initializer exactly once and you need to make sure that
this occurrence is invoked before all the others at run
But where do you expand it without the SAVE_EXPR? The same
restrictions apply there. So I suppose you expand it to a function
in which case there is the context where the SAVE_EXPR can be
expanded exactly once.
You don't have SAVE_EXPRs so you're precisely controlling what you're doing.
Hm, ok. I was more looking at removing the calls from fold-const.c where
it seems to protect things like folding x = +Inf to x == x, stuff unlikely
to appear in type sizes. I can imagine the Ada FE wanting to do
things with type sizes and variable_size's wrapping looks like merely
an
Well - the errors in variable_size aren't used by C any more (since 4.5),
but I don't know whether any other languages use them.
Apparently not, let's remove them.
And pending sizes are used to a limited extent for C (to handle side effects
in sizes of array parameters, as described in the
On Tue, May 3, 2011 at 6:15 PM, Xinliang David Li davi...@google.com wrote:
On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka hubi...@ucw.cz wrote:
Is this one ok?
Hi,
we did quite some work on removing a langhooks for LTO, where they become
quite impossible
So I would like to know what testcase
Umm, I think most of them (if not all) are just bogus. If a FE doesn't
want to fold some stuff when at global scope it should not call fold.
That isn't so easy because fold is invoked on sizes of types by stor-layout.c
and these sizes can be variable (at least in Ada). So I think that the
On Wed, 4 May 2011, Eric Botcazou wrote:
That isn't so easy because fold is invoked on sizes of types by stor-layout.c
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b)
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b) folding done by front ends only when required
for language semantics (e.g. constant expressions). If you want to
optimize
On Wed, May 4, 2011 at 12:00 PM, Eric Botcazou ebotca...@adacore.com wrote:
Umm, I think most of them (if not all) are just bogus. If a FE doesn't
want to fold some stuff when at global scope it should not call fold.
That isn't so easy because fold is invoked on sizes of types by
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b) folding done by front ends only when required
for language semantics (e.g. constant expressions).
Why? Isn't it
Hi,
On Wed, 4 May 2011, Richard Guenther wrote:
It prevents save_expr from being called at global level, since you
cannot create SAVE_EXPRs outside functions. Likewise in
variable_size.
I see several places in fold-const.c that are not properly guarded then.
But anyway, if it is
On Wed, May 4, 2011 at 1:56 PM, Michael Matz m...@suse.de wrote:
Hi,
On Wed, 4 May 2011, Richard Guenther wrote:
It prevents save_expr from being called at global level, since you
cannot create SAVE_EXPRs outside functions. Likewise in
variable_size.
I see several places in
On Wed, May 4, 2011 at 07:44, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote:
That's what we should phase out. The eventual aim should be for (a)
folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees)
as an optimization and (b) folding done by front ends only when required
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in the literature.
Sure, in the sorts of examples you mention where there's a level
On Wed, May 4, 2011 at 08:30, Richard Kenner ken...@vlsi1.ultra.nyu.edu wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in
Hi,
On Wed, 4 May 2011, Richard Kenner wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in the literature.
Sure, in
On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For instance, loop unrolling and vectorization.
There are others in the
On Wed, May 4, 2011 at 09:19, Nathan Froyd froy...@codesourcery.com wrote:
On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote:
There are pros and cons about early optimization, actually.
Generating extremely optimized IL very early can actually tie up
subsequent passes. For
I think we may be talking at different levels. It's my impression
that Richard K. was referring to local transformations like a - a -
0 once we are in the middle end. I agree that doing that
transformation close to the FE is undesirable, but once we are in the
middle end that should be
And I'm not sure you can't do SAVE_EXPRs outside of functions - you
could simply emit global temporaries.
How do you initialize global temporaries with non-trivial initializers?
--
Eric Botcazou
On Wed, May 4, 2011 at 5:10 PM, Eric Botcazou ebotca...@adacore.com wrote:
And I'm not sure you can't do SAVE_EXPRs outside of functions - you
could simply emit global temporaries.
How do you initialize global temporaries with non-trivial initializers?
Actually it turns out that it doesn't
Actually it turns out that it doesn't matter. If we arrive here with
something that needs a SAVE_EXPR we have to be able to generate code
for it somewhere, where there would be obviously the possibility to
also generate code for a SAVE_EXPR.
The transformations done in fold are optimizations
Joseph I don't know if Fortran, Java or Go use variable-size types at
Joseph all.
Java doesn't have variable-size types.
AFAIK, gcj does not generate them internally for anything, either.
Tom
On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka hubi...@ucw.cz wrote:
Is this one ok?
Hi,
we did quite some work on removing a langhooks for LTO, where they become
quite impossible
So I would like to know what testcase causes the problem and why.
In fold-const.c, there are many of calls to
In fold-const.c, there are many of calls to
lang_hooks.decls.global_bindings_p, and the implementation of this in
name-lookup.h will look at the the cfun-language
#define cp_function_chain (cfun-language)
#define current_binding_level \
(*(cfun cp_function_chain
I am however completely missing the point of this langhook and doc is not
exactly informative either:
/* Returns nonzero if we are in the global binding level. Ada
returns -1 for an undocumented reason used in stor-layout.c. */
What is the purpose of this hook?
I've seen things
On Tue, 3 May 2011, Eric Botcazou wrote:
I am however completely missing the point of this langhook and doc is not
exactly informative either:
/* Returns nonzero if we are in the global binding level. Ada
returns -1 for an undocumented reason used in stor-layout.c. */
What
On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
In my view we should require front ends to take responsibility for
variable-size types, and get rid of this language-independent function
(copying such parts as are needed into the front ends that need them). C
for example
On Tue, 3 May 2011, Nathan Froyd wrote:
On Tue, May 03, 2011 at 07:06:58PM +, Joseph S. Myers wrote:
In my view we should require front ends to take responsibility for
variable-size types, and get rid of this language-independent function
(copying such parts as are needed into the
In my view we should require front ends to take responsibility for
variable-size types, and get rid of this language-independent function
(copying such parts as are needed into the front ends that need them).
I don't really see the point here. GCC supports variable-sized types in the
On Tue, May 03, 2011 at 07:27:24PM +, Joseph S. Myers wrote:
On Tue, 3 May 2011, Nathan Froyd wrote:
The raft of changes/improvements enabled by this change would be most
welcome. *_SIZE becoming double_ints or HOST_WIDE_INT instead of trees
is the first thing that comes to mind;
On Tue, 3 May 2011, Eric Botcazou wrote:
In my view we should require front ends to take responsibility for
variable-size types, and get rid of this language-independent function
(copying such parts as are needed into the front ends that need them).
I don't really see the point here.
C returns -1 from global_bindings_p, as does Ada. That the languages that
probably care most about variable-size types find aspects of the generic
function need overriding like that should be a good indication that it
isn't really that generic - as I said above, semantics for variable sizes
On Tue, 3 May 2011, Eric Botcazou wrote:
C returns -1 from global_bindings_p, as does Ada. That the languages that
probably care most about variable-size types find aspects of the generic
function need overriding like that should be a good indication that it
isn't really that generic -
Is this one ok?
David
On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li davi...@google.com wrote:
During function cloning, the language field of the src func is not
copied. This can lead to null dereference when gcc calls into langhook
functions. Unfortunately, I lost track of the test
During function cloning, the language field of the src func is not
copied. This can lead to null dereference when gcc calls into langhook
functions. Unfortunately, I lost track of the test case.
Ok for trunk ?
Thanks,
David
2011-04-29 Xinliang David Li davi...@google.com
*
37 matches
Mail list logo
