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: [PATCH] Fix sched-ebb.c bug (was Re: [3.3 branch] IA64bootstrap failure) (take 2)


Sorry about the delay.  I took an unexpected "vacation" from gcc work,
and ended up leaving this hanging.  I am still behind on gcc-patches
email, but I don't think this has been resolved yet.

On Wed, 2003-07-16 at 08:55, Jakub Jelinek wrote:
> All VALUE rtxs with CSELIB_VAL_PTR(value)->locs == 0 should behave
> the same in alias.c unless the identical VALUE is on both sides

It isn't clear to me that this is safe.  Part of the problem here is
that cselib_subst_to_values doesn't just return VALUE rtx.  It returns
an address rtx which may have some or all parts replaced with VALUE
rtx.  You won't see this on IA-64, because the only addressing mode
IA-64 has is REG, and a REG will always be replaced with a VALUE. 
However, if I compile for a powerpc target using
-fsched2-use-superblocks, I see stuff like this
(plus:SI (value:SI)
    (const_int -88 [0xffffffffffffffa8]))

This means that your sched_discard_callback function is not complete. 
You need to search the mem address RTL for VALUE rtxes, instead of just
checking to see if the mem address RTL is a VALUE rtx.  This will make
the code less efficient, but perhaps not much more so.

It also complicates the treatment of VALUE RTL in alias.c.  If we have
arbitrary RTL that may have been substituted with VALUE RTL, then I
don't think it is safe to say that we get correct results, i.e. that all
of these address alias each other.  There are also complexities from
MEM_OFFSET and MEM_SIZE which are used by some routines.  Suppose we
have two MEMs with different bases, and MEM_OFFSET/MEM_SIZE values that
would cause them to overlap if they had the same base.  Now suppose the
bases are replaced with cselib_unknown_address.  alias may claim that
they don't overlap because of the MEM_OFFSET/MEM_SIZE values, however if
we still had the base values, then they might have overlapped because of
those values.  This is a difficult thing to check, but I think this is a
real problem with your proposal.  This won't show up for an IA-64 target
because IA-64 has only REG addresses.

Perhaps we should just stop using cselib_subst_to_values in
sched-deps.c.  This might be the best solution if there is little
performance benefit of these calls.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


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