Re: Hi, do you still mess around with gcc/g++ on HPUX?

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

Forwarded message:
From dave Tue Oct 24 15:39:02 EDT 2000
Message-Id: <200010241939.PAA01592@hiauly1.hia.nrc.ca>
Subject: Re: Hi, do you still mess around with gcc/g++ on HPUX? (fwd)
To: dave@hiauly1.hia.nrc.ca (John David Anglin)
Date: Tue, 24 Oct 2000 15:39:01 -0400 (EDT)
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: law@cygnus.com
In-Reply-To: <no.id> from "John David Anglin" at Oct 22, 2000 01:03:49 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> >   > I think there is something wrong with the edge determination.  Basic block
> >   > 0 has 61 edges on the pa.  There are two on the i686.  Can't see where
> >   > all these edges are coming from in what is more or less linear code.
> > Very odd.  Can you send me the RTL dump for BB 0?
> 
> This has something to do with the determination of basic blocks when
> exceptions are used.  If I run cc1plus with -fno-exceptions on the pa,
> there isn't a problem.  With exceptions, maybe the problem has something
> to do with the call to __get_eh_context that appears at the start of bb 0.
> The i686 rtl doesn't have this in its rtl.

I think I more or less understand what is happening.  The pa port uses sjlj
exceptions as the default.  When this exception mode is used, the function
expand_builtin_setjmp sets nonlocal_goto_handler_labels.  When this is
true, call insns with no REG_EH_REGION notes will set call_had_abnormal_edge
to 1 (see line 590 in flow.c).  This would appear to be the origin of the
large number of edges and the large amount of memory needed for gcse.

I don't really understand the gcse code but I have the sense that 
nonlocal_goto_handler_labels shouldn't be considered.  If that is wrong,
then sjlj-exceptions and gcse don't work well together, and possibly,
sjlj-exceptions shouldn't be the default mode.  It appears that this
default changes to no-sjlj-exceptions on machines that define
DWARF2_UNWIND_INFO to be 1.  This appears to be another reason to
implement DWARF2 unwinding.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)