public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64217] LRA: generate wrong liveness info after r217947 for clobber in jump_insn
Date: Tue, 09 Dec 2014 20:35:00 -0000 [thread overview]
Message-ID: <bug-64217-4-J8LKUaaHsx@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-64217-4@http.gcc.gnu.org/bugzilla/>
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.
next prev parent reply other threads:[~2014-12-09 20:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-08 7:29 [Bug rtl-optimization/64217] New: " npickito at gmail dot com
2014-12-09 20:35 ` vmakarov at gcc dot gnu.org [this message]
2014-12-12 4:08 ` [Bug target/64217] " jasonwucj at gcc dot gnu.org
2014-12-16 6:51 ` jasonwucj at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-64217-4-J8LKUaaHsx@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).