This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More help to my port. nospam ("nospam" subjects are now BLOCKED)

Please do not send the same message multiple times.  The 'nospam' in the
subject has no significance to the mailing list software so you
essentially end up spamming the list with duplicate messages.

I've blocked future email which contains the term 'nospam', just to help make
this point.

On Fri, Sep 05, 2003 at 04:02:59PM +0200, Anders ?dland wrote:
>Sorry for bothering you again, but I don't want to do too many misstakes...
>The insn
>(set (mem:SI (reg:SI 76))
>      (reg:SI 83))
>is changed to
>(set (mem:SI (plus:SI (reg:SI 39)
>                       (reg:SI 154)))
>      (reg:SI 83))
>in the instruction combination pass. This can be done because the 
>template's predicate functions is returning non-zero. Later, in the global 
>register allocation pass, pseudo register 154 is moved to the stack and 
>the insn is changed to
>(set (mem:SI (plus:SI (reg:SI 39)
>                       (plus:SI (reg:SI 6 r7)
>                                (const_int -16))))
>      (reg:SI 2 r3))
>which is an illegal pattern.
>I know that LEGITIMATE_ADDRESS is defined in two versions depending on if 
>REG_OK_STRICT is defined or not, but this macro is only used to check if 
>the first version of the insn is legal, not the others. They are only 
>checked by the template's predicate function. To solve the problem I had 
>to change the predicate function to not allow pseudo registers where 
>(reg:SI 154) is located in the insn. This would however make less 
>optimized code if the pseudo can be mapped to a hard register.
>How can I solve this problem?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]