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