Re: RFA: patch to solve PR37535

[Richard Sandiford <rdsandiford at googlemail dot com>]

Vladimir Makarov <vmakarov@redhat.com> writes:
> The following patch solves the PR37535.  The analysis of the problem can 
> be found on
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535

Thanks for the patch.  But my understanding is that (clobber (reg X))
is an earlyclobber for register-allocation purposes, not an output
clobber.  C.f. the following bit of rtl.texi:

    When a @code{clobber} expression for a register appears inside a
    @code{parallel} with other side effects, the register allocator
    guarantees that the register is unoccupied both before and after that
    insn.

It does go on to say:

    ... However, the reload phase may allocate a register used for one of
    the inputs unless the @samp{&} constraint is specified for the selected
    alternative (@pxref{Modifiers}).  You can clobber either a specific hard
    register, a pseudo register, or a @code{scratch} expression; in the
    latter two cases, GCC will allocate a hard register that is available
    there for use as a temporary.

but I don't think that makes any difference for these pa and s390 patterns,
where the input operands are hard regs that are either hard-coded into
the .md file, or that have empty constraints.

I notice you said:

    Unfortunately using DF for building conflicts became more
    complicated that it was before based on REG notes.  So it will take
    some time.

I'm sorry to hear that you're so unhappy with that change.  I'm happy
to back it out if you'd prefer.  (Really.)

Richard