Hi,
I tested the following patch. It makes inliner to ignore empty EH clenaup
regions regadless they are internal or external in anticipation they will be
removed. It also make tree-eh to not do any cleanups pre-inline. This is
independent change, but I wanted to stress the code bit more.
Here ar
Hi,
On Wed, 29 Jan 2014, Jakub Jelinek wrote:
> > > It is also problem of inliner quality decisions and memory
> > > use/compile time. The in-memory representation of unnecesary EH is
> > > quite big.
> > >
> > > I am quite ignorant in this area, but for -O0 can't we simply
> > > disable all
> But that will badly regress the stack usage, won't it? If so, that's a
> blocker for Ada where we have big temporaries.
For example this will presumably cause gnat.dg/stack_usage1.adb to fail.
--
Eric Botcazou
> That sounds reasonable, yeah.
But that will badly regress the stack usage, won't it? If so, that's a
blocker for Ada where we have big temporaries.
--
Eric Botcazou
On Wed, Jan 29, 2014 at 03:06:45PM +0100, Michael Matz wrote:
> Hi,
>
> On Tue, 28 Jan 2014, Jan Hubicka wrote:
>
> > It is also problem of inliner quality decisions and memory use/compile
> > time. The in-memory representation of unnecesary EH is quite big.
> >
> > I am quite ignorant in this
Hi,
On Tue, 28 Jan 2014, Jan Hubicka wrote:
> It is also problem of inliner quality decisions and memory use/compile
> time. The in-memory representation of unnecesary EH is quite big.
>
> I am quite ignorant in this area, but for -O0 can't we simply disable
> all clobbers?
That sounds reason
> Hi,
>
> On Tue, 28 Jan 2014, Richard Biener wrote:
>
> > >> The EH optimizations involving cleanups with only clobbers in them
> > >> are that if at the end of the cleanup after only CLOBBER stmts you
> > >> would rethrow the exception externally, then the clobber isn't needed
> > >> and the
Hi,
On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 28, 2014 at 01:48:21PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> >
> > > There are two kinds of clobbers, the direct ones, which surely can be
> > > safely removed by ehcleanup1 if they are
On Tue, Jan 28, 2014 at 01:48:21PM +0100, Michael Matz wrote:
> Hi,
>
> On Tue, 28 Jan 2014, Jakub Jelinek wrote:
>
> > There are two kinds of clobbers, the direct ones, which surely can be
> > safely removed by ehcleanup1 if they are the only reason why there is a
> > landing pad which will be
Hi,
On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> There are two kinds of clobbers, the direct ones, which surely can be
> safely removed by ehcleanup1 if they are the only reason why there is a
> landing pad which will be rethrown outside of the current function,
You can only safely (as in, not
Hi,
On Tue, 28 Jan 2014, Richard Biener wrote:
> >> The EH optimizations involving cleanups with only clobbers in them
> >> are that if at the end of the cleanup after only CLOBBER stmts you
> >> would rethrow the exception externally, then the clobber isn't needed
> >> and the whole cleanup c
On Tue, Jan 28, 2014 at 11:48:16AM +0100, Richard Biener wrote:
> On Mon, Jan 20, 2014 at 5:22 PM, Jan Hubicka wrote:
> >>
> >> Yes. Say, this could be surrounded by some try/catch, if we do it the
> >> first
> >> way, a would be still considered live across the EH path to whatever
> >> catches
On Mon, Jan 20, 2014 at 5:22 PM, Jan Hubicka wrote:
>>
>> Yes. Say, this could be surrounded by some try/catch, if we do it the first
>> way, a would be still considered live across the EH path to whatever catches
>> it.
>>
>> The EH optimizations involving cleanups with only clobbers in them are
>
> Yes. Say, this could be surrounded by some try/catch, if we do it the first
> way, a would be still considered live across the EH path to whatever catches
> it.
>
> The EH optimizations involving cleanups with only clobbers in them are that
> if at the end of the cleanup after only CLOBBER s
On Mon, Jan 20, 2014 at 05:07:18PM +0100, Jan Hubicka wrote:
> So I guess we can not modify giplifier to output
> foo (&a.buf);
> a.buf[6] = 1;
> a.buf[7] = 8;
> a = {CLOBBER};
>
> instead of
>
> try
> {
> foo (&a.buf);
> a.buf[6] = 1;
>
> >struct A { char buf[64]; };
> >void foo (char *);
> >void test ()
> >{
> > { A a; foo (a.buf); a.buf[6] = 1; a.buf[7] = 8; }
> > { A a; foo (a.buf); a.buf[6] = 1; a.buf[7] = 8; }
> > { A a; foo (a.buf); a.buf[6] = 1; a.buf[7] = 8; }
> > { A a; foo (a.buf); a.buf[6] = 1; a.buf[7] = 8; }
> >
Jakub Jelinek wrote:
>On Sun, Jan 19, 2014 at 11:46:09PM +0100, Jan Hubicka wrote:
>> Bootstrapped/regtested x86_64-linux, OK?
>
>This looks very wrong. By ignoring the clobbers in the cleanups you
>ensure clobbers are hardly ever emitted, but the TRY/FINALLY is the way
>how
>to make sure the clo
On Sun, Jan 19, 2014 at 11:46:09PM +0100, Jan Hubicka wrote:
> Bootstrapped/regtested x86_64-linux, OK?
This looks very wrong. By ignoring the clobbers in the cleanups you
ensure clobbers are hardly ever emitted, but the TRY/FINALLY is the way how
to make sure the clobbers appear in all the place
Hi,
when compiling:
struct A
{
virtual int foo (void) {return 42;}
};
int test (void)
{
struct A a, *b=&a;
return b->foo();
}
We wind up the following useless EH:
int test() ()
{
int D.2235;
int (*__vtbl_ptr_type) () * D.2236;
int (*__vtbl_ptr_type) () D.2237;
struct A a;
stru
19 matches
Mail list logo
