[PATCH] [ARC] Add single/double IEEE precission FPU support.

Claudiu Zissulescu Claudiu.Zissulescu@synopsys.com
Tue Feb 9 15:34:00 GMT 2016


Please find attached a reworked patch. It doesn't contain the ABI modifications as I notified you earlier in an email.  Also, you may have extra comments regarding these original observations:

>+  /* ARCHS has 64-bit data-path which makes use of the even-odd paired
>+     registers.  */
>+  if (TARGET_HS)
>+    {
>+      for (regno = 1; regno < 32; regno +=2)
>+       {
>+         arc_hard_regno_mode_ok[regno] = S_MODES;
>+       }
>+    }
>+
>
>Does TARGET_HS with -mabi=default allow for passing DFmode / DImode 
>arguments
>in odd registers?  I fear you might run into reload trouble when trying to
>access the values.

The current ABI passes the DI-like modes in any register pair. This should not be an issue as the movdi_insn and movdf_insn should handle those exceptional cases. As for partial passing of arguments, move_block_from_reg() should take care of exceptional cases like DImode.

>+             if (!link_insn
>+                 /* Avoid FPU instructions.  */
>+                 || (GET_MODE (SET_DEST
>+                               (PATTERN (link_insn))) == CC_FPUmode)
>+                 || (GET_MODE (SET_DEST
>+                               (PATTERN (link_insn))) == CC_FPU_UNEQmode)
>+                 || (GET_MODE (SET_DEST
>+                               (PATTERN (link_insn))) == CC_FPUEmode))
>
>It's pointless to search for the CC setter and then bail out this late.
>The mode is also accessible in the CC user, so after we have computed
>pc_target, we can check the condition code register in the comparison
>XEXP (pc_target, 1) for its mode.

Most of the cases checking only the CC user may be sufficient. However, there are cases (only one which I found), where the CC user has a different mode than of the CC setter.  This is happening when running gcc.dg/pr56424.c test. Here, the C_FPU mode cstore is simplified by the following steps losing the CC_FPU mode:

In the expand:
   18: cc:CC_FPU=cmp(r159:DF,r162:DF)
   19: r163:SI=cc:CC_FPU<0
   20: r161:QI=r163:SI#0
   21: r153:SI=zero_extend(r161:QI)
   22: cc:CC_ZN=cmp(r153:SI,0)
   23: pc={(cc:CC_ZN!=0)?L28:pc}

Then after combine we get this:
   18: cc:CC_FPU=cmp(r2:DF,r4:DF)
      REG_DEAD r4:DF
      REG_DEAD r2:DF
   23: pc={(cc:CC_ZN<0)?L28:pc}
      REG_DEAD cc:CC_ZN
      REG_BR_PROB 6102

Ok to apply?
Claudiu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARC-Add-single-double-IEEE-precission-FPU-support.patch
Type: application/octet-stream
Size: 52674 bytes
Desc: 0001-ARC-Add-single-double-IEEE-precission-FPU-support.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160209/9e395fb0/attachment.obj>


More information about the Gcc-patches mailing list