This is the mail archive of the gcc-bugs@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]

[Bug rtl-optimization/64217] LRA: generate wrong liveness info after r217947 for clobber in jump_insn


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64217

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #1 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Thanks for reporting this.  I've reproduced the bug.  LRA treats p47 as an
input therefore after adding live info update to LRA, p47 live range becomes
such long.

The insn in question has the following definition

(define_insn "casesi_internal"
  [(parallel [(set (pc)
                   (mem:SI (plus:SI (mult:SI (match_operand:SI 0
"register_operand" "r")
                                             (const_int 4))
                                    (label_ref (match_operand 1 "" "")))))
              (use (label_ref (match_dup 1)))
              (clobber (match_operand:SI 2 "register_operand" ""))
              (clobber (reg:SI TA_REGNUM))])]

I think it is wrong.  GCC documentation says

@cindex @samp{=} In constraint
@item =
Means that this operand is written to by this instruction:
the previous value is discarded and replaced by new data.

As clobber always discards the previous value, it should have '=' which is
absent for this insn definition.  The constraints for LRA is usually more
important than other info.  After saying that, you can understand that the of
absence of other constraints is confusing to me. For example, clobber could get
memory in LRA and that will conflict finally with register_operand predicate
(but the conflict will probably recognized in assembler only as operand
predicates are used mostly in combiner and rtl generation).  But may be I am
wrong and the intention was that memory also works for the insn.

So I'd add at least '=' but it is better to add '=r' or '=<some other register
constraint>' to solve the problem.

If such fix is not acceptable for you for some reasons, let me know.  I'll
think how this undefined behaviour (it is really a grey area) can be fixed in
LRA.


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