From mboxrd@z Thu Jan  1 00:00:00 1970
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
Message-ID: <200002291823.SAA12545@rocoto>
X-SW-Source: 2000-q1/msg00304.html
Message-ID: <20000401000000.ndcI45fDRcVuWX3jDVBqmgkQ7AJNF8IlFP7o-SVkvnM@z>

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
==============================================================================