public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Immediate Problems at the Reload Phase of GCC
@ 2000-02-29 10:23 Paul Webster
  2000-02-29 10:29 ` Jeffrey A Law
  2000-04-01  0:00 ` Paul Webster
  0 siblings, 2 replies; 4+ messages in thread
From: Paul Webster @ 2000-02-29 10:23 UTC (permalink / raw)
  To: gcc-help; +Cc: pmw

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Immediate Problems at the Reload Phase of GCC
  2000-02-29 10:23 Immediate Problems at the Reload Phase of GCC Paul Webster
@ 2000-02-29 10:29 ` Jeffrey A Law
  2000-04-01  0:00   ` Jeffrey A Law
  2000-04-01  0:00 ` Paul Webster
  1 sibling, 1 reply; 4+ messages in thread
From: Jeffrey A Law @ 2000-02-29 10:29 UTC (permalink / raw)
  To: Paul Webster; +Cc: gcc-help

  In message < 200002291823.SAA12545@rocoto >you write:
  > 
  > This question is regarding gcc version 2.95.2.
  > 
  > I am working with an instruction set that contains an immediate and registe
  > r
  > 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.
Use a single define_insn with multiple alternative constraints.  

  > I guess the solution is to block this propogation in the reload phase?
No.  That would just paper over the problem.

jeff



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Immediate Problems at the Reload Phase of GCC
  2000-02-29 10:23 Immediate Problems at the Reload Phase of GCC Paul Webster
  2000-02-29 10:29 ` Jeffrey A Law
@ 2000-04-01  0:00 ` Paul Webster
  1 sibling, 0 replies; 4+ messages in thread
From: Paul Webster @ 2000-04-01  0:00 UTC (permalink / raw)
  To: gcc-help; +Cc: pmw

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Immediate Problems at the Reload Phase of GCC
  2000-02-29 10:29 ` Jeffrey A Law
@ 2000-04-01  0:00   ` Jeffrey A Law
  0 siblings, 0 replies; 4+ messages in thread
From: Jeffrey A Law @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Paul Webster; +Cc: gcc-help

  In message < 200002291823.SAA12545@rocoto >you write:
  > 
  > This question is regarding gcc version 2.95.2.
  > 
  > I am working with an instruction set that contains an immediate and registe
  > r
  > 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.
Use a single define_insn with multiple alternative constraints.  

  > I guess the solution is to block this propogation in the reload phase?
No.  That would just paper over the problem.

jeff



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-29 10:23 Immediate Problems at the Reload Phase of GCC Paul Webster
2000-02-29 10:29 ` Jeffrey A Law
2000-04-01  0:00   ` Jeffrey A Law
2000-04-01  0:00 ` Paul Webster

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).