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]
Other format: [Raw text]

Re: [dataflow] PATCH removal of more of flow.c.

Kenneth Zadeck wrote:

Paolo Bonzini wrote:

Index: struct-equiv.c
--- struct-equiv.c (revision 115422)
+++ struct-equiv.c (working copy)
@@ -989,10 +989,6 @@ bool
struct_equiv_init (int mode, struct equiv_info *info)
if ((info->x_block->flags | info->y_block->flags) & BB_DIRTY)
- update_life_info_in_dirty_blocks (UPDATE_LIFE_GLOBAL_RM_NOTES,
if (!REG_SET_EQUAL_P (DF_LR_OUT (rtl_df, info->x_block),

I will fix this, as far as I could determine, this was dead code anyway.
If this is resurrected it will need create it's own copy of df and
destroy it when it is finished since it cannot rely on persistent
dataflow info any more.

This code was only supposed to be temporarily disabled over Christmas.

The first if statement is not removed.

Also, it may be worthwhile to put a comment in config/sh/sh.c that its
machine dependent reorg pass is looking at LOG_LINKS even though they
are all NULL.

It is hard to see how this could be correct unless the uses are called
immediately after combine or scheduling since no other passes even try
to keep this up to date.

machine_dependent_reorg used to run immediately after sched2 (ignoring reg-stack,
which does not run on the SH).
It seems some more passes have been wedged in now, I'm don't know if they
make a difference.
That being said, I would welcome a change of this code to something more
solid, as long as we end up with something that works in practice.

The objective is to find constant loads where we can account for all the uses
as some sort of function call; if that is the case, we emit a label before the load,
and .uses <label> pseudo-ops before the uses of the register. The assembler &
linker can use this information to provide link-time-relaxation, i.e. when
all the calls can be implemented with the limited-range branch-to-subroutine
instruction , the constant load, and usually the constant, can be eliminated.
There has also been discussion of extending this scheme to other kinds of
loads and uses, e.g. TLS accesses:

To formulate this in DF terms, we'd need to solve both RU and RD.
For each potentially eligible definition, we'll have to examine each use
(RU) to verify that we might be able to do without the value or use a simpler
version of it by doing link-time relaxation, and that all its definitions (RD)
load the same value.

Strictly speaking, we don't need to solve a complete RU problem; we could
restrict the exact tracking of uses as caused by a specific instruction to uses that
are actually potential candidates for relaxation, and consider all the other uses of
the same register as a single use (we can't get rid of them with relaxation, hence it
doesn't matter how many there are exactly and where there are, only if there is
none or at least one).
Moreover, only the hard register r0..r14 are of interest, we can't do any relaxation
with other registers.
I don't know if formulating such restricted RU problems would fit into the DF


The cleanup sequence then is like this:
- cleanup the now dead code in the SH back-end.

Huh? Which code is now dead?

Flow is not going quietly. The last patch has been really hard to track
down the last side effects. My best people are fighting an entrenched
battle even as we speak.

This might sound be funny, but it paints a wrong picture. Flow is not the enemy.
It's more like an old employee reaching retirement, and you find out that (s)he's
been so entrenched in the company infrastructure you have to hire five new people
to cover all his/her responsibilities.

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