* GO_IF_LEGITIMATE_ADDRESS handling different addressing modes for load/store
@ 2012-11-28 18:37 Ayonam Ray
2012-11-28 18:44 ` Jeff Law
0 siblings, 1 reply; 3+ messages in thread
From: Ayonam Ray @ 2012-11-28 18:37 UTC (permalink / raw)
To: gcc-help
Hi,
My architecture allows base + immed and base + index for loads but
allows only base + immed for stores. How do I differentiate between
them in the macro GO_IF_LEGITIMATE_ADDRESS? I only get the MEM rtx in
that macro and have no clue whether the operand is an address for a
load or a store. Is there any other way that I can differentiate
between them?
Thanks and regards
Ayonam
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GO_IF_LEGITIMATE_ADDRESS handling different addressing modes for load/store
2012-11-28 18:37 GO_IF_LEGITIMATE_ADDRESS handling different addressing modes for load/store Ayonam Ray
@ 2012-11-28 18:44 ` Jeff Law
2012-11-29 4:44 ` Ayonam Ray
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Law @ 2012-11-28 18:44 UTC (permalink / raw)
To: Ayonam Ray; +Cc: gcc-help
On 11/28/2012 11:37 AM, Ayonam Ray wrote:
> Hi,
>
> My architecture allows base + immed and base + index for loads but
> allows only base + immed for stores. How do I differentiate between
> them in the macro GO_IF_LEGITIMATE_ADDRESS? I only get the MEM rtx in
> that macro and have no clue whether the operand is an address for a
> load or a store. Is there any other way that I can differentiate
> between them?
You can't differentiate them. Fundamentally the register allocator
assumes that a memory address is either valid or invalid regardless of
whether or not it's a load or store.
What ports have done in the past with this situation is to support the
lowest common denominator in the movxx pattern, then add special
constraints for the cases that are only available on the load (or store).
For an example, see how indexed addressing modes are handled on the PA.
It has integer indexed loads, but no integer indexed stores. It has
indexed loads and stores for floating point types.
jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GO_IF_LEGITIMATE_ADDRESS handling different addressing modes for load/store
2012-11-28 18:44 ` Jeff Law
@ 2012-11-29 4:44 ` Ayonam Ray
0 siblings, 0 replies; 3+ messages in thread
From: Ayonam Ray @ 2012-11-29 4:44 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-help
Thanks Jeff for the clue. Much appreciated.
Regards
Ayonam
On 29 November 2012 00:14, Jeff Law <law@redhat.com> wrote:
> On 11/28/2012 11:37 AM, Ayonam Ray wrote:
>>
>> Hi,
>>
>> My architecture allows base + immed and base + index for loads but
>> allows only base + immed for stores. How do I differentiate between
>> them in the macro GO_IF_LEGITIMATE_ADDRESS? I only get the MEM rtx in
>> that macro and have no clue whether the operand is an address for a
>> load or a store. Is there any other way that I can differentiate
>> between them?
>
> You can't differentiate them. Fundamentally the register allocator assumes
> that a memory address is either valid or invalid regardless of whether or
> not it's a load or store.
>
> What ports have done in the past with this situation is to support the
> lowest common denominator in the movxx pattern, then add special constraints
> for the cases that are only available on the load (or store).
>
> For an example, see how indexed addressing modes are handled on the PA. It
> has integer indexed loads, but no integer indexed stores. It has indexed
> loads and stores for floating point types.
>
> jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-11-29 4:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-28 18:37 GO_IF_LEGITIMATE_ADDRESS handling different addressing modes for load/store Ayonam Ray
2012-11-28 18:44 ` Jeff Law
2012-11-29 4:44 ` Ayonam Ray
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).