PIC code for coldfire v4e

PIC code for coldfire v4e

[C Jaiprakash, Noida]

Hi,
  I am trying to provide PIC support  for coldfire v4e. Curently movsi pattern generates PIC code , basically it generates a RTX like PLUS(a5, symbolic_operand) where a5 is PIC offset table pointer. And at the final assembly o/p @GOT is appended to the symbol if base register is a5.  For coldfire v4e this can not be done because only 16 bit offset is allowed. May be something like 
  lea running@GOT.w, %register
  move.l (%a5,%register), %a0
instead of 
 move.l running@GOT.w(%a5),%a0

will have to be done. But i am facing implementation problems for this. I can not force_reg symbolic operand in "movsi" pattern. I tried to split this later but the problem is print_operand_address relies on base register for adding @GOT while assembly generation, which will not happen if i spilt the "movsi" insn. Any hint where cani do this? Below is "movsi" 
pattern for reference. 

(define_expand "movsi"
  [(set (match_operand:SI 0 "nonimmediate_operand" "")
        (match_operand:SI 1 "general_operand" ""))]
  ""
  "
{
  if (flag_pic && !TARGET_PCREL && symbolic_operand (operands[1], SImode))
    {
      /* The source is an address which requires PIC relocation.
         Call legitimize_pic_address with the source, mode, and a relocation
         register (a new pseudo, or the final destination if reload_in_progress
         is set).   Then fall through normally */
      rtx temp = reload_in_progress ? operands[0] : gen_reg_rtx (Pmode);

      operands[1] = legitimize_pic_address (operands[1], SImode, temp);
    }
  else if (flag_pic && TARGET_PCREL && ! reload_in_progress)
    {
      /* Don't allow writes to memory except via a register;
         the m68k doesn't consider PC-relative addresses to be writable.  */
      if (symbolic_operand (operands[0], SImode))
        operands[0] = force_reg (SImode, XEXP (operands[0], 0));
      else if (GET_CODE (operands[0]) == MEM
               && symbolic_operand (XEXP (operands[0], 0), SImode))
        operands[0] = gen_rtx (MEM, SImode,
                               force_reg (SImode, XEXP (operands[0], 0)));
    }
}")


cj

Re: PIC code for coldfire v4e

[Andreas Schwab]

"C Jaiprakash, Noida" <C.Jaiprakash@noida.hcltech.com> writes:

> Hi,
>   I am trying to provide PIC support  for coldfire v4e. Curently movsi pattern generates PIC code , basically it generates a RTX like PLUS(a5, symbolic_operand) where a5 is PIC offset table pointer. And at the final assembly o/p @GOT is appended to the symbol if base register is a5.  For coldfire v4e this can not be done because only 16 bit offset is allowed. May be something like 
>   lea running@GOT.w, %register
>   move.l (%a5,%register), %a0
> instead of 
>  move.l running@GOT.w(%a5),%a0
                     ^^

This is already a 16 bit offset.  For -fpic (as opposed to -fPIC) you
don't have to change anything here.  You could just declare -fPIC
unsupported for this coldfire model (like it is done for m680[01]0.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PIC code for coldfire v4e

[Peter Barada]

>> Hi,
>>   I am trying to provide PIC support  for coldfire v4e. Curently movsi pattern generates PIC code , basically it generates a RTX like PLUS(a5, symbolic_operand) where a5 is PIC offset table pointer. And at the final assembly o/p @GOT is appended to the symbol if base register is a5.  For coldfire v4e this can not be done because only 16 bit offset is allowed. May be something like 
>>   lea running@GOT.w, %register
>>   move.l (%a5,%register), %a0
>> instead of 
>>  move.l running@GOT.w(%a5),%a0
>                     ^^
>
>This is already a 16 bit offset.  For -fpic (as opposed to -fPIC) you
>don't have to change anything here.  You could just declare -fPIC
>unsupported for this coldfire model (like it is done for m680[01]0.)

See:
http://gcc.gnu.org/ml/gcc/2002-12/msg00343.html

for the start of a thread where I tried to implement this back in
2002.  Perhaps it will shortcut some of the issues you are about to
get run over by.  Unfortunately I ran out of time before I was able to fully
implement/test it...

Andres, see:
http://gcc.gnu.org/ml/gcc/2002-12/msg00345.html
for my response to your same suggestion :)

-- 
Peter Barada
peter@the-baradas.com