public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).