public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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
==============================================================================

             reply	other threads:[~2000-04-01  0:00 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).