This is the mail archive of the 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]

Re: egcs-19980803 (pre-1.1) solaris regressions

>    Date: Tue, 18 Aug 1998 10:42:04 -0600
>    From: Jeffrey A Law <>
>    This is a bug in reorg.  I belive it is supposed to handle these
>    kinds of inconsistencies in the rtl and basic_block_* data
>    structures.
> Actually I think it is a combination of bugs, 2 I can see at the
> moment:
> 1) As you mention reorg is broken.  I walked through the example and
>    it does not find the basic blocks correctly and does not scan
>    the necessary instructions to find resource usages while scheduling
>    a delay instrution.  In this case, it does not set the ANNUL bit in
>    the instruction because of lost information.

I suppose it's a matter of perspective whether one regards flow as broken 
or reorg as broken, but from a practical standpoint of long-term code 
maintenance, it seems better to fix one compiler pass (flow) to provide 
accurate information instead of trying to kludge n other compiler passes 
to deal with inaccurate information.

I've been thinking about the NOTE_INSN_DELETED scheme, and it seems 
all compiler passes rely upon basic_block_head[n] to point to an actual 
insn and not a note, so a megapatch to modify all passes which are basic 
block information dependent would be required, which is probably bad.

It seems a scheme whereby new basic block information is introduced, but 
the current basic block information is retained would be better, since 
compiler passes could be converted one by one to utilize the new 
information without causing a flag day for everyone.

This could be done by introducing two new note types: NOTE_BASIC_BLOCK_BEGIN
and NOTE_BASIC_BLOCK_END, and providing corresponding arrays
new_basic_block_head[]/new_basic_block_end[], while retaining the current 
basic_block arrays. The compiler passes could be converted one by one 
over to the new basic block information, and when all passes are 
converted, the old basic block information could be removed.

Does this sound reasonable?


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