> 2009/4/8 Sylvain Pion :
>
> > Maybe, but for exceptions which are relatively local, say, inside a given
> > library, the user can assume that GCC has switched to the "local ABI" with
> > fast internal exceptions, since he may have compiled the library as one
> > translation unit, so he may be ab
2009/4/8 Sylvain Pion :
> Maybe, but for exceptions which are relatively local, say, inside a given
> library, the user can assume that GCC has switched to the "local ABI" with
> fast internal exceptions, since he may have compiled the library as one
> translation unit, so he may be able to contro
Jan Hubicka a écrit :
EH throwing is so costly (2 cycles minimum reported in PR 6588) that,
in some cases, even if it's exceptional, like a 10^-4 probability
of throwing, you will see it show up on the profile.
Having EH delivery at reasonnable speed would really open up the design
space : i
> Jan Hubicka a écrit :
> >>Sylvain Pion a écrit :
> >>>Naive user question : is this going to improve the efficiency
> >>>of throwing exceptions, at least in the restricted cases of :
> >
> >There is little improvement already via EH cleanup: at least
> >cleanups/catch regions that turns out to be
Jan Hubicka a écrit :
Sylvain Pion a écrit :
Naive user question : is this going to improve the efficiency
of throwing exceptions, at least in the restricted cases of :
There is little improvement already via EH cleanup: at least
cleanups/catch regions that turns out to be empty are now elimin
I was wondering if loops of form
for (i=0; ; i++)
a[i]
can be assumed finite because eventaully a[i] would get to unallocated
memory otherwise. This is however similar to inifinite recursion
Correct me if I'm wrong but this is definitely wrong...
Assuming a 64bit processor and i to
> Sylvain Pion a écrit :
> >Naive user question : is this going to improve the efficiency
> >of throwing exceptions, at least in the restricted cases of :
There is little improvement already via EH cleanup: at least
cleanups/catch regions that turns out to be empty are now eliminated and
does not
Sylvain Pion a écrit :
Naive user question : is this going to improve the efficiency
of throwing exceptions, at least in the restricted cases of :
- the catch clause contains the throw (after inlining).
I meant the try block, sorry.
- interprocedural analysis can connect th
Naive user question : is this going to improve the efficiency
of throwing exceptions, at least in the restricted cases of :
- the catch clause contains the throw (after inlining).
- interprocedural analysis can connect the throwing spot and
the corresponding catch clause.
?
See my old PR 6588.
On Wed, Apr 8, 2009 at 5:19 PM, Richard Guenther wrote:
>> - We ought to be able to prove finitarity of simple loops so we can
>> DCE more early and won't rely on full loop unrolling to get rid of
>> empty loops originally initializing dead arrays.
>
> I wonder if CD-DCE should not catch
> On Wed, 8 Apr 2009, Jan Hubicka wrote:
>
> > Some remaining issues:
> > - FILTER_EXPR/OBJ_REF_EXPR is currently handled in quite dangerous way.
> > Original Rth's code made them quite 100% volatile. Now we can PRE them.
> > The FILTER_EXPR/OBJ_REF_EXPR are really hard registers in RTL
> For instance
> for (i=0; i can be optimized out for signed counter relying that overflow can jump
> in between max...INT_MAX
>
> togehter with loops of style
> for (i=0; i in unsigned, and for MAX known and safely away from end of type we
> should prove finiteness in most common cases.
Pleas
On Wed, 8 Apr 2009, Jan Hubicka wrote:
> > On Wed, 8 Apr 2009, Richard Guenther wrote:
> >
> > > On Wed, 8 Apr 2009, Jan Hubicka wrote:
> > > > - The nature of code duplication in between cleanup at end of block
> > > > and
> > > > cleanup in EH actually brings a lot of tail merging possib
> On Wed, 8 Apr 2009, Richard Guenther wrote:
>
> > On Wed, 8 Apr 2009, Jan Hubicka wrote:
> > > - The nature of code duplication in between cleanup at end of block and
> > > cleanup in EH actually brings a lot of tail merging possibilities.
> > > I wonder if we can handle this somehow e
On Wed, 8 Apr 2009, Richard Guenther wrote:
> On Wed, 8 Apr 2009, Jan Hubicka wrote:
> > - The nature of code duplication in between cleanup at end of block and
> > cleanup in EH actually brings a lot of tail merging possibilities.
> > I wonder if we can handle this somehow effectivly on
On Wed, 8 Apr 2009, Jan Hubicka wrote:
> Some remaining issues:
> - FILTER_EXPR/OBJ_REF_EXPR is currently handled in quite dangerous way.
> Original Rth's code made them quite 100% volatile. Now we can PRE them.
> The FILTER_EXPR/OBJ_REF_EXPR are really hard registers in RTL world that
Hi,
while looking into problems of current and pretty-ipa's inlining heuristics
implementation, I noticed that we have relatively important problems with EH
overhead that confuse inliner code size metrics.
Looking deeper into EH problems, I think main issues are:
- Inliner tends to produce expo
17 matches
Mail list logo
