This is the mail archive of the gcc@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: birthpoints in rtl.


On Sat, Mar 1, 2008 at 3:01 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
>
>  > it is more productive to spend the cycles getting rid of the libcalls
>  > rather than figuring out the edge cases.   as steven implied, we have
>  > been on the verge of getting rid of them for years and just have just
>  > not fixed the last reason.   The amount of time that we spent in 4.3
>  > fixing the last two libcall bugs could have been much better spent just
>  > ditching them.
>
>  I think both problems are orthogonal.  One way of modeling libcalls
>  would be stringing all the insns in the libcall sequence with a single
>  DF object that's defined and used by all the insns in the sequence.

And there's another special-case treatment for libcalls. On top of
REG_LIBCALL/REG_RETVAL/REG_LIBCALL_ID. This is bug prone.  For GCC 4.3
alone, I've fixed half a dozen libcall blocks related bugs, and others
have fixed at least as many. Not to mention all the extra work they
caused for the people working on the df branch. They were a major
headache.

You're right technically: The problems are orthogonal in the sense
that it *can* be done.  But I, for one, would not even start working
on RTL-FUD before libcall blocks are dead and gone. Just because I
wouldn't want to handle it as a special case that

Gr.
Steven


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