From: pmw@uk.research.att.com (Paul Webster)
To: gcc-help@gcc.gnu.org
Cc: pmw@uk.research.att.com
Subject: Immediate Problems at the Reload Phase of GCC
Date: Tue, 29 Feb 2000 10:23:00 -0000 [thread overview]
Message-ID: <200002291823.SAA12545@rocoto> (raw)
This question is regarding gcc version 2.95.2.
I am working with an instruction set that contains an immediate and register
based compare for equality instruction. The immediate version can take a 16-bit
signed value and a register. The register version takes two registers.
Currently, I have a define_insn for the register comparison. I also have a
define_insn for the immediate variation, constrained to only accept 16-bit
signed values.
However, I have also been trying to have a define_expand instruction that can
take any 32-bit immediate value. If the range of the immediate is able to fit
into a 16-bit value, then it expands to a single immediate compare instruction.
If it is too large to fit into this value, the expand forces the immediate into
a register and then generates a register comparison.
(The reason for needing the expand, is I am trying to minimise the number of
compare instructions required, so the expand effectively maps the 10
`standard' compare operations down to my minimal subset. I'd like it to be
general enough to accept any 32-bit constant values, just for orthogonality)
My problem is that the re-load phase is spotting the register I created in the
expand is only ever used in the subsequent comparison, and GCC then does some
form of constant propogation of the value back into the compare instruction.
This constant propogation ignores the fact that the range of the immediate
cannot hold the particular value and I get an error.
It looks as if the compiler realises that there is a signature for an immediate
comparison operation that is basically the same as the register based one and
doesn't check that the value will fit. At the reload stage, the constraint on
the immediate is then being checked and I get an error that reloads cannot be
generated. I would have thought this shouldn't be an `error'; it should just
not have tried to propogate the constant in the first place?
I guess the solution is to block this propogation in the reload phase? I
suspect the problem is caused by the way I have organised the compares, so any
hints on a good way to reorganise them would be helpful (I am sure this sort of
problem must have been encountered before in one of the other ports?).
Thank you in advance for any hints anyone can offer.
Cheers,
Paul
==============================================================================
AT&T Laboratories Cambridge
------------------------------------------------------------------------------
Dr. Paul Webster, 24a Trumpington Street, Cambridge, CB2 1QA, England.
Tel: +44 (0)1223 343 218 Fax: +44 (0)1223 313542
==============================================================================
WARNING: multiple messages have this Message-ID
From: pmw@uk.research.att.com (Paul Webster)
To: gcc-help@gcc.gnu.org
Cc: pmw@uk.research.att.com
Subject: Immediate Problems at the Reload Phase of GCC
Date: Sat, 01 Apr 2000 00:00:00 -0000 [thread overview]
Message-ID: <200002291823.SAA12545@rocoto> (raw)
Message-ID: <20000401000000.ndcI45fDRcVuWX3jDVBqmgkQ7AJNF8IlFP7o-SVkvnM@z> (raw)
This question is regarding gcc version 2.95.2.
I am working with an instruction set that contains an immediate and register
based compare for equality instruction. The immediate version can take a 16-bit
signed value and a register. The register version takes two registers.
Currently, I have a define_insn for the register comparison. I also have a
define_insn for the immediate variation, constrained to only accept 16-bit
signed values.
However, I have also been trying to have a define_expand instruction that can
take any 32-bit immediate value. If the range of the immediate is able to fit
into a 16-bit value, then it expands to a single immediate compare instruction.
If it is too large to fit into this value, the expand forces the immediate into
a register and then generates a register comparison.
(The reason for needing the expand, is I am trying to minimise the number of
compare instructions required, so the expand effectively maps the 10
`standard' compare operations down to my minimal subset. I'd like it to be
general enough to accept any 32-bit constant values, just for orthogonality)
My problem is that the re-load phase is spotting the register I created in the
expand is only ever used in the subsequent comparison, and GCC then does some
form of constant propogation of the value back into the compare instruction.
This constant propogation ignores the fact that the range of the immediate
cannot hold the particular value and I get an error.
It looks as if the compiler realises that there is a signature for an immediate
comparison operation that is basically the same as the register based one and
doesn't check that the value will fit. At the reload stage, the constraint on
the immediate is then being checked and I get an error that reloads cannot be
generated. I would have thought this shouldn't be an `error'; it should just
not have tried to propogate the constant in the first place?
I guess the solution is to block this propogation in the reload phase? I
suspect the problem is caused by the way I have organised the compares, so any
hints on a good way to reorganise them would be helpful (I am sure this sort of
problem must have been encountered before in one of the other ports?).
Thank you in advance for any hints anyone can offer.
Cheers,
Paul
==============================================================================
AT&T Laboratories Cambridge
------------------------------------------------------------------------------
Dr. Paul Webster, 24a Trumpington Street, Cambridge, CB2 1QA, England.
Tel: +44 (0)1223 343 218 Fax: +44 (0)1223 313542
==============================================================================
next reply other threads:[~2000-02-29 10:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-29 10:23 Paul Webster [this message]
2000-02-29 10:29 ` Jeffrey A Law
2000-04-01 0:00 ` Jeffrey A Law
2000-04-01 0:00 ` Paul Webster
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=200002291823.SAA12545@rocoto \
--to=pmw@uk.research.att.com \
--cc=gcc-help@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).