Kenneth Zadeck wrote:
Richard Sandiford wrote:
Hi Joern,
Thanks for the answer,
Joern Rennecke <[EMAIL PROTECTED]> writes:
Thanks very much for replying to this. We were starting to get worried
that no one was going to reply and we would be left out in the cold.
Some of us might be on va
The second is to say explicitly that
subregs of subregs are not legal.
Yes, you should always use (directly or indirectly) simplify_gen_subreg.
Paolo
Richard Sandiford wrote:
Richard Sandiford <[EMAIL PROTECTED]> writes:
- A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode.
...except that (as the docs said) an unknown number of bits read as undefined.
Richard
I would add two things to the section. One is to
Richard Sandiford <[EMAIL PROTECTED]> writes:
> - A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode.
...except that (as the docs said) an unknown number of bits read as undefined.
Richard
Thanks again to everyone who commented. In sumnmary:
- There was disagreement about whether subregs of hard registers
should be phased out. However, we still have some code to handle
them, and they are still used today (at least by SPE).
- A MODE_PARTIAL_INT mode behaves like the co
On Thu, 20 Mar 2008, Bernd Schmidt wrote:
> Joseph S. Myers wrote:
> > Yes. For SPE, the subregs used in these *frob_* patterns represent concepts
> > including the high-part of a register (only used by certain instructions
> > that treat registers as 64 bits) and a DImode value stored in one 64-
Joseph S. Myers wrote:
Yes. For SPE, the subregs used in these *frob_* patterns represent
concepts including the high-part of a register (only used by certain
instructions that treat registers as 64 bits) and a DImode value stored in
one 64-bit register (normal layout is in two) or a DFmode va
On Thu, 20 Mar 2008, Bernd Schmidt wrote:
> Paolo Bonzini wrote:
> > SPE has patterns for
> >
> > [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
> > (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))]
> >
> > for example.
>
> What are they trying to do? It
Paolo Bonzini wrote:
SPE has patterns for
[(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
(subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))]
for example.
What are they trying to do? It's dubious for a number of reasons:
- SUBREG in the instruction patter
Joern Rennecke <[EMAIL PROTECTED]> writes:
> On Thu, Mar 20, 2008 at 10:39:47AM +, Richard Sandiford wrote:
>> you're saying that, for any valid values of M and X:
>>
>> (set (subreg:M (reg:N ...) X) (const_int 0))
>>
>> does not guarantee that (subreg:M (reg:N ...) ...) has the value 0
>>
Bernd Schmidt wrote:
Joern Rennecke wrote:
And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to
express that
you are using the floating point register as a 32 bit integer register,
with writes clobbering the entire 64 bit of the register.
Yes, this is one possible definition. But th
Joern Rennecke wrote:
And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to express that
you are using the floating point register as a 32 bit integer register,
with writes clobbering the entire 64 bit of the register.
Yes, this is one possible definition. But there's no reason in this
On Thu, Mar 20, 2008 at 10:39:47AM +, Richard Sandiford wrote:
> you're saying that, for any valid values of M and X:
>
> (set (subreg:M (reg:N ...) X) (const_int 0))
>
> does not guarantee that (subreg:M (reg:N ...) ...) has the value 0
> if N is a partial mode?
Yes. Although it will be
> > I think one reason is that allowing zero_extracts of multi-word modes is
> > (like this subreg thing) a little hard to pin down. What happens when
> > WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
>
> Unless I had my grep wrong, the only such machines to do this are PDP11
> and ARM with special flag
(Yes, the documentation suggests byte_mode for MEMs, but the SH port
uses zero_extracts of SImode MEMs as well, so presumably we're supposed
to support other modes besides the documented ones.)
I think it is just that no one cares about a MEM's mode in this case.
Paolo
Richard Sandiford wrote:
Paolo Bonzini <[EMAIL PROTECTED]> writes:
I think one reason is that allowing zero_extracts of multi-word modes is
(like this subreg thing) a little hard to pin down. What happens when
WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
Unless I had my grep wrong, the only such machi
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> I think one reason is that allowing zero_extracts of multi-word modes is
>> (like this subreg thing) a little hard to pin down. What happens when
>> WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
>
> Unless I had my grep wrong, the only such machines to do this
Sorry for snipping a lot, but I think the important bit was...
Joern Rennecke <[EMAIL PROTECTED]> writes:
> But the SUBREGS and ZERO_EXTRACTs should still mean the same with respect to
> selecting groups of bits. You simply don't know which of them mean anything
> and what their positional value
I think one reason is that allowing zero_extracts of multi-word modes is
(like this subreg thing) a little hard to pin down. What happens when
WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
Unless I had my grep wrong, the only such machines to do this are PDP11
and ARM with special flags (-mbig-endia
On Wed, Mar 19, 2008 at 10:56:29PM +, Richard Sandiford wrote:
> > I don't see why the target-independent code would need to know what the bits
> > inside a partial integer mode mean.
>
> Consider:
>
>(set (subreg:HI (reg:PDI ...) ...) ...)
>(set (zero_extract (subreg:SI (reg:PDI ...)
Richard Sandiford <[EMAIL PROTECTED]> writes:
> I think one reason is that allowing zero_extracts of multi-word modes is
> (like this subreg thing) a little hard to pin down. What happens when
> WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN on a 32-bit target, and you have:
>
> (zero_extract (reg:DI .
Joern Rennecke <[EMAIL PROTECTED]> writes:
> On Tue, Mar 18, 2008 at 09:40:49PM +, Richard Sandiford wrote:
>> > The most natural layout would be 0x45??0123 .
>> > But you could also have 0x345?012? , or even more exotic mappings.
>>
>> Do we actually support the second mapping though? Surely
On Tue, Mar 18, 2008 at 09:40:49PM +, Richard Sandiford wrote:
> > The most natural layout would be 0x45??0123 .
> > But you could also have 0x345?012? , or even more exotic mappings.
>
> Do we actually support the second mapping though? Surely the
> target-independent code needs to know how
Richard Sandiford wrote:
Hi Joern,
Thanks for the answer,
Joern Rennecke <[EMAIL PROTECTED]> writes:
Thanks very much for replying to this. We were starting to get worried
that no one was going to reply and we would be left out in the cold.
kenny
1) Is it possible to have a MODE_PARTI
Hi Joern,
Thanks for the answer,
Joern Rennecke <[EMAIL PROTECTED]> writes:
>> 1) Is it possible to have a MODE_PARTIAL_INT inner register that is bigger
>> than a word?
>
> Yes. You might have a 20 bit register, which is considered Pmode == PHImode,
> with a lower half QImode (16 bit, word add
> 1) Is it possible to have a MODE_PARTIAL_INT inner register that is bigger
> than a word?
Yes. You might have a 20 bit register, which is considered Pmode == PHImode,
with a lower half QImode (16 bit, word addressed) which can be accessed
separately by arithmetic instructions.
> If so, what r
> That's my understanding too as far as insn operands are concerned.
> But some backends use things like "(subreg (match_operand ...) ...)";
> see config/rs6000/spe.md for an example. We need to define what those
> subregs mean when the inner register has been reloaded.
>
> Or I suppose we could
Hi Richard,
Thanks for the message.
[EMAIL PROTECTED] (Richard Kenner) writes:
>> It is seldom necessary to wrap hard registers in @code{subreg}s;
>> such registers would normally reduce to a single @code{reg} rtx.
>
> Are these valid? I know we've gone back and forth, but I thought the
> curren
> It is seldom necessary to wrap hard registers in @code{subreg}s;
> such registers would normally reduce to a single @code{reg} rtx.
Are these valid? I know we've gone back and forth, but I thought the
current position is that SUBREGs of hard regs are only allowed
transitorily (e.g., during relo
Jeff, DJ and Richard,
Richard Sandiford and I have taken on the task of trying to fully
explain subregs in the gcc docs. This is an area where that
traditionally has been very confusing to outsiders and even insiders who
were not rtl maintainers. As the community of active developers has
30 matches
Mail list logo
