This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Fix Ada bootstrap (was: 16: EH redirection)


2009/4/30 Jan Hubicka <hubicka@ucw.cz>:
>> On Thu, Apr 30, 2009 at 12:50 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > I do not know how to fix this properly. ?I can either make DCE to not
>> > remove unreachable blocks and remove them somewhere later, or simply
>> > drop DCE flag on DSE df_analyze or declare that it is up to caller to
>> > cleanup CFG after calling df_analyze with DCE flag when df_analyze
>> > somehow signalizes that it removed some throwing instructions or make
>> > DCE to update the bitmap?
>>
>> I'd let DCE update the bitmap. ?It should know which blocks have
>> disappeared (we're not running compact_blocks, right?)
>
> That would imply passing the bitmap around to DCE, writting custom
> version of delete_unreachable_blocks (that is not big deal given it is
> single loop checking reachability flag and calling delete_block).

Or a post-pass after DCE,

bitmap remaining_bbs = BITMAP_ALLOC (&df_bitmap_obstack);
FOR_EACH_BB(bb)
  bitmap_set_bit (remaining_bbs, bb->index);
bitmap_and_into (all_blocks, remaining_bbs);
bitmap_free (remaining_bbs);

> ?But I
> am bit concerned about fact that the passes calling df_analyze with a
> bitmap often use the bitmap later. ?I don't think they expect the bitmap
> to change? I.e. DSE itself it attaching info to BBs, computing the
> bitmap, the calling analyze and I think it will just leak the info if
> the BB disappears.

That, I don't know -- haven't looked.  But if it attaches info to BBs,
then it's probably obstack-allocated or pool-allocated, so I don't
think anything would leak.

Ciao!
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]