[PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)

[Mark Mitchell]

Daniel Berlin wrote:
>> These REG_LIBCALL_ID notes would need to be actively maintained throughout the
>> entire RTL middle-end and I don't see any practical advantages over what we
>> currently have.  And of course someone needs to do the implementation.
> 
> If you don't see the practical advantage of being able to determine
> whether an insn is part of a libcall without having to walk the entire
> function to figure out whether you are allowed to touch an insn,
> please just remove it.
> God forbid we ever start somewhere and work towards a goal.
> Really.
> I'm completely done working on our backend or trying to improve it in any way.
> I'm removing my name from the dataflow maintainer list.

Let's all take a deep breath here.

In.

Out.

In.

Out.

Wow, I feel so centered...

Losing our tempers won't help.  There's an honest disagreement here
between two long-standing GCC contributors.  No need for dramatics.

(I'd be willing to host/moderate a regular conference call for any/all
interested GCC developers to use to discuss Issues of the Day.  I know
it's old-tech, but if people are interested, let me know.  Phone still
seems to work better to resolve some issues than IRC/email.)

Now, to the design issue at hand.  REG_LIBCALL_ID seems a better way to
represent libcalls than the longstanding begin/end structure for the
reason Danny stated: you can tell what instruction is in what libcall
without walking around in the instruction stream.  So, we don't want to
be removing it, we want to be moving towards it.

But, because we're presently dependent on the old structures, it sounds
to me like we need to make sure that no non-libcall instructions are
inserted between REG_LIBCALL and REG_RETVAL.  That's the bug.  We should
find the code doing that, and make it stop -- until we complete this
transition.  That's what Jakub is trying to do.

As for half-baked transitions (or, to use Zack's original phraseology,
"incomplete transitions"), yup, we have them.  My experience is that
most other folks do to.  I've certainly seen a fair number of
proprietary compilers with weird, half-used legacy bits in them.  I'm
not sure there's a way around them; if you demand there be no incomplete
transitions at all, you raise the bar for changing things pretty far.
The dataflow bar was already pretty high, and Kenny, Danny, Seongbae,
et. al. all worked pretty hard for a long time to get that stuff in good
shape.  As Danny says, at some point, you have to declare victory.

(We are making progress, though, by organizing things into smaller, more
self-contained units.  For example, the various optimization passes are
much more replaceable than ever before.  We're doing a better job
separating the front ends from the middle end.  This is good.)

Danny, do you think Jakub's patch is correct?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713