> 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 o
On Thu, May 5, 2011 at 12:07 PM, Eric Botcazou wrote:
>> 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
> 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.
On Thu, May 5, 2011 at 11:23 AM, Eric Botcazou wrote:
>> 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 sur
> 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 r
On Wed, May 4, 2011 at 7:14 PM, Eric Botcazou 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 generate code for a S
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
> 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 optimizati
On Wed, May 4, 2011 at 5:10 PM, Eric Botcazou 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 matter. If we arr
> 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
> 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 shoul
On Wed, May 4, 2011 at 09:19, Nathan Froyd 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 instance, loop unr
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 li
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.
>
> S
On Wed, May 4, 2011 at 08:30, 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.
>
> S
> 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 le
On Wed, May 4, 2011 at 07:44, Richard Kenner 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
>> for language sema
On Wed, May 4, 2011 at 1:56 PM, Michael Matz 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 fold-c
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
> 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 a
On Wed, May 4, 2011 at 12:00 PM, Eric Botcazou 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 stor-layout.c
> and these si
> 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
> opti
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) fo
> 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 c
On Tue, May 3, 2011 at 6:15 PM, Xinliang David Li wrote:
> On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka 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 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 th
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 gene
> 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 size
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 he
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;
> 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
middl
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
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, 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. */
> 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 thi
> 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_functio
On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka 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
lang_hooks.de
> 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.
Honza
>
> David
>
> On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li wrote:
> > During function cloning, the lang
Is this one ok?
David
On Fri, Apr 29, 2011 at 4:38 PM, Xinliang David Li 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 case.
>
> Ok for tru
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
* tree-inline.c (ininitializ
40 matches
Mail list logo
