Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> The target macros described in the "Addressing Modes" section of the
>> internals manual are rather badly in need of cleaning up.
>
> What's your status on this - would you mind very much if I made
> changes to those macros now?
Zack Weinberg wrote:
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up.
What's your status on this - would you mind very much if I made changes
to those macros now?
Bernd
Ian Lance Taylor writes:
> I think this change is a great idea. I want to point out something
> you probably already noticed: some definitions of
> LEGITIMIZE_RELOAD_ADDRESS rely on the fact that they appear in
> reload.c in the only caller, find_reloads_address. For example, the
> definition i
Zack Weinberg <[EMAIL PROTECTED]> writes:
> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros. All callers are changed to
> use the hooks. The default definitions of the hooks invoke the
> existing macros. The hardest part of this is work
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I have worked out a tentative plan for replacing most of these macros
>> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
>> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_AD
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
This idiom i
Kazu Hirata <[EMAIL PROTECTED]> writes:
> Hi Zack,
>
>> So, the plan: Step 1 introduces - one at a time - target hooks
>> corresponding to each of the above macros. All callers are changed to
>> use the hooks.
...
>> Step 2 is to convert each architecture, one at a time, to make
>> target-hook d
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> I have worked out a tentative plan for replacing most of these
>> macros with ordinary target hooks, and eliminating REG_OK_STRICT.
>
> Are you planning to keep the observed behaviour, or do you want to
> make any enhancements that
Hi Dave,
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
Sure. In fact, the FRV port and possible
An explicit Addressing Mode or mechanism to enable the identification
of "read-only" rtl static data references, there by enabling uC, and/or
DSP's with Harvard memory architectures, which typically require the use
of specialized load instructions to access it's ROM based program memory
space, to e
Original Message
>From: gcc-owner On Behalf Of Kazu Hirata
>Sent: 28 February 2005 14:41
> So I would change each macro to an
> architecture-specific function in each architecture first. For
> example, GO_IF_LEGITIMATE_ADDRESS should look like this (taken from
> i386.h):
>
> #ifdef REG_
> Zack Weinberg
> The target macros described in the "Addressing Modes" section of the
> internals manual are rather badly in need of cleaning up. I see three
> primary reasons why this is so:
- Very Nice; and wonder, although somewhat orthogonal, if it would be
similarly desirable to clean up
Zack Weinberg <[EMAIL PROTECTED]> writes:
> I have worked out a tentative plan for replacing most of these macros
> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
> LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRE
Hi Zack,
> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros. All callers are changed to
> use the hooks. The default definitions of the hooks invoke the
> existing macros. The hardest part of this is working out exactly what
> their sole
Zack Weinberg wrote:
I have worked out a tentative plan for replacing most of these macros
with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRESS, REG_OK_FOR_BASE_P,
REG_MO
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up. I see three
primary reasons why this is so:
1) These are the macros subject to REG_OK_STRICT. For those of you
who have managed so far to avoid finding out about thi
16 matches
Mail list logo
