[PATCH] [ARC] Add single/double IEEE precission FPU support.
In this patch, we add support for the new FPU instructions available with ARC V2 processors. The new FPU instructions covers both single and double precision IEEE formats. While the single precision is available for both ARC EM and ARC HS processors, the double precision is only available for ARC HS. ARC EM will make use of the double precision assist instructions which are in fact FPX double instructions. The double floating point precision instructions are making use of the odd-even register pairs to hold 64-bit datums, exactly like in the case of ldd/std instructions. Additional to the mods required by FPU instructions to be supported by GCC, we forced all the 64 bit datum to use odd-even register pairs (HS only), as we observed a better usage of the ldd/std, and less generated move instructions. A byproduct of this optimization, is a new ABI, which places the 64-bit arguments into odd-even register pairs. This behavior can be selected using -mabi option. Feedback is welcomed, Claudiu gcc/ 2016-02-01 Claudiu Zissulescu * config/arc/arc-modes.def (CC_FPU, CC_FPUE, CC_FPU_UNEQ): New modes. * config/arc/arc-opts.h (FPU_SP, FPU_SF, FPU_SC, FPU_SD, FPU_DP) (FPU_DF, FPU_DC, FPU_DD, FXP_DP): Define. (arc_abi_type): New enum. * config/arc/arc-protos.h (arc_init_cumulative_args): Declare. * config/arc/arc.c (TARGET_STRICT_ARGUMENT_NAMING): Define. (arc_init): Check FPU options. (get_arc_condition_code): Handle new CC_FPU* modes. (arc_select_cc_mode): Likewise. (arc_conditional_register_usage): Allow 64 bit datum into even-odd register pair only. Allow access for ARCv2 accumulator. (gen_compare_reg): Whenever we have FPU support use FPU compare instructions. (arc_setup_incoming_varargs): Handle even-odd register pair (ARC HS only). (arc_strict_argument_naming): New function. (arc_init_cumulative_args): Likewise. (arc_hard_regno_nregs): Likewise. (arc_function_args_impl): Likewise. (arc_arg_partial_bytes): Use arc_function_args_impl function. (arc_function_arg): Likewise. (arc_function_arg_advance): Likewise. (arc_reorg): Don't generate brcc insns when FPU compare instructions are involved. * config/arc/arc.h (TARGET_DPFP): Add TARGET_FP_DPAX condition. (TARGET_OPTFPE): Add condition when ARC EM can use optimized floating point emulation. (ACC_REG_FIRST, ACC_REG_LAST, ACCL_REGNO, ACCH_REGNO): Define. (CUMULATIVE_ARGS): New structure. (INIT_CUMULATIVE_ARGS): Use arc_init_cumulative_args. (REVERSE_CONDITION): Add new CC_FPU* modes. (TARGET_HARD_FLOAT, TARGET_FP_SINGLE, TARGET_FP_DOUBLE) (TARGET_FP_SFUZED, TARGET_FP_DFUZED, TARGET_FP_SCONV) (TARGET_FP_DCONV, TARGET_FP_SSQRT, TARGET_FP_DSQRT) (TARGET_FP_DPAX): Define. * config/arc/arc.md (ARCV2_ACC): New constant. (type): New fpu type attribute. (SDF): Conditional iterator. (cstore, cbranch): Change expand condition. (addsf3, subsf3, mulsf3, adddf3, subdf3, muldf3): New expands, handles FPU/FPX cases as well. * config/arc/arc.opt (mfpu, mabi): New options. * config/arc/fpx.md (addsf3_fpx, subsf3_fpx, mulsf3_fpx): Renamed. (adddf3, muldf3, subdf3): Removed. * config/arc/predicates.md (proper_comparison_operator): Recognize CC_FPU* modes. * config/arc/fpu.md: New file. * doc/invoke.texi (ARC Options): Document mabi and mfpu options. --- gcc/config/arc/arc-modes.def | 5 + gcc/config/arc/arc-opts.h| 27 ++ gcc/config/arc/arc-protos.h | 1 + gcc/config/arc/arc.c | 398 - gcc/config/arc/arc.h | 70 -- gcc/config/arc/arc.md| 150 ++- gcc/config/arc/arc.opt | 56 + gcc/config/arc/fpu.md| 580 +++ gcc/config/arc/fpx.md| 64 + gcc/config/arc/predicates.md | 10 + gcc/doc/invoke.texi | 91 ++- 11 files changed, 1310 insertions(+), 142 deletions(-) create mode 100644 gcc/config/arc/fpu.md diff --git a/gcc/config/arc/arc-modes.def b/gcc/config/arc/arc-modes.def index b64a596..1f4bf95 100644 --- a/gcc/config/arc/arc-modes.def +++ b/gcc/config/arc/arc-modes.def @@ -35,3 +35,8 @@ CC_MODE (CC_FPX); VECTOR_MODES (INT, 4);/*V4QI V2HI */ VECTOR_MODES (INT, 8);/* V8QI V4HI V2SI */ VECTOR_MODES (INT, 16); /* V16QI V8HI V4SI V2DI */ + +/* FPU conditon flags. */ +CC_MODE (CC_FPU); +CC_MODE (CC_FPUE); +CC_MODE (CC_FPU_UNEQ); diff --git a/gcc/config/arc/arc-opts.h b/gcc/config/arc/arc-opts.h index 0f12885..be628e5 100644 --- a/gcc/config/arc/arc-opts.h +++ b/gcc/config/arc/arc-opts.h @@ -27,3 +27,30 @@ enum processor_type PROCESSOR_ARCEM, PROCESSOR_ARCHS }; + +/* Single precisio
Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.
On 10/02/16 13:31, Claudiu Zissulescu wrote: Please find attached the amended patch for FPU instructions. Ok to apply? +(define_insn "*cmpdf_fpu" I'm wondering - could you compare with +zero using a literal (adding an alternative)? (No need to hold up the main patch, but you can consider it for a follow-up patch) (define_insn "*cmpsf_fpu_uneq" + [(set (reg:CC_FPU_UNEQ CC_REG) + (compare:CC_FPU_UNEQ +(match_operand:DF 0 "even_register_operand" "r") Typo: probably should be *cmpdf_fpu_uneq +case CC_FPUmode: + return !((code == LTGT) || (code == UNEQ)); ` strictly speaking, this shouldn't accept unsigned comparisons, although I can't think of a scenario where these would be presented in this mode, and the failure mode would just be an abort in get_arc_condition_code. Otherwise, this is OK.
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
Thanks Joern, Committed: r233451 > -Original Message- > From: Joern Wolfgang Rennecke [mailto:g...@amylaar.uk] > Sent: Saturday, February 13, 2016 12:42 AM > To: Claudiu Zissulescu; gcc-patches@gcc.gnu.org > Cc: francois.bed...@synopsys.com; jeremy.benn...@embecosm.com > Subject: Re: [PATCH] [ARC] Add single/double IEEE precission FPU support. > > > > On 10/02/16 13:31, Claudiu Zissulescu wrote: > > Please find attached the amended patch for FPU instructions. > > > > Ok to apply? > +(define_insn "*cmpdf_fpu" > > I'm wondering - could you compare with +zero using a literal (adding an > alternative)? > (No need to hold up the main patch, but you can consider it for a follow-up > patch) > > (define_insn "*cmpsf_fpu_uneq" > + [(set (reg:CC_FPU_UNEQ CC_REG) > + (compare:CC_FPU_UNEQ > +(match_operand:DF 0 "even_register_operand" "r") > > Typo: probably should be *cmpdf_fpu_uneq > > +case CC_FPUmode: > + return !((code == LTGT) || (code == UNEQ)); > ` > strictly speaking, this shouldn't accept unsigned comparisons, although I > can't > think of a scenario where these would be presented in this mode, and the > failure mode would just be an abort in get_arc_condition_code. > > Otherwise, this is OK.
Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.
On 01/02/16 13:57, Claudiu Zissulescu wrote: In this patch, we add support for the new FPU instructions available with ARC V2 processors. The new FPU instructions covers both single and double precision IEEE formats. While the single precision is available for both ARC EM and ARC HS processors, the double precision is only available for ARC HS. ARC EM will make use of the double precision assist instructions which are in fact FPX double instructions. The double floating point precision instructions are making use of the odd-even register pairs to hold 64-bit datums, exactly like in the case of ldd/std instructions. Additional to the mods required by FPU instructions to be supported by GCC, we forced all the 64 bit datum to use odd-even register pairs (HS only), as we observed a better usage of the ldd/std, and less generated move instructions. A byproduct of this optimization, is a new ABI, which places the 64-bit arguments into odd-even register pairs. This behavior can be selected using -mabi option. Feedback is welcomed, VECTOR_MODES (INT, 16); /* V16QI V8HI V4SI V2DI */ + +/* FPU conditon flags. */ Typo + error ("FPU double precission options are available for ARC HS only."); There should be no period at the end of the error message string. + if (TARGET_HS && (arc_fpu_build & FPX_DP)) + error ("FPU double precission assist " Typo. And Ditto. + case EQ: + case NE: + case UNORDERED: + case UNLT: + case UNLE: + case UNGT: + case UNGE: + return CC_FPUmode; + + case LT: + case LE: + case GT: + case GE: + case ORDERED: + return CC_FPUEmode; cse and other code transformations are likely to do better if you use just one mode for these. It is also very odd to have comparisons and their inverse use different modes. Have you done any benchmarking for this? @@ -1282,6 +1363,16 @@ arc_conditional_register_usage (void) arc_hard_regno_mode_ok[60] = 1 << (int) S_MODE; } + /* 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. +arc_hard_regno_nregs (int regno, ... + if ((regno < FIRST_PSEUDO_REGISTER) + && (HARD_REGNO_MODE_OK (regno, mode) + || (mode == BLKmode))) +return words; + return 0; This prima facie contradicts HARD_REGNO_NREGS, which considers the larger sizes of simd vector and dma config registers. I see that there is no actual conflict as the vector registers are not used for argument passing, but the comment in the function only states what the function does - not quite correctly, as detailed before - and not what it is for. So, either the mxp support has to be removed before this patch goes in, or arc_hard_regno_nregs has to handle simd registers properly, or the comment at the top should state the limited applicability of this function, and there should be an assert to check that the register number passed is suitable - e.g.: gcc_assert (regno < ARC_FIRST_SIMD_VR_REG) +/* Given an CUMULATIVE_ARGS, this function returns an RTX if the Typo: C is not a vowel. + if (!named && TARGET_HS) +{ + /* For unamed args don't try fill up the reg-holes. */ + reg_idx = cum->last_reg; + /* Only interested in the number of regs. */ You should make up your mind what the priorities for stdarg are. Traditionally, lots of gcc ports have supported broken code that lacks declarations of variadic functions, and furthermore have placed emphasis on simplicity of varargs/stdarg callee code, at the expense of normal code. Often for compatibility with a pre-existing compiler, sometimes by just copying from existing ports without stopping to consider the ramifications. If you make argument passing different for stdarg declared functions, the broken code that lacks declarations won't work any more. Ignoring registers for argument passing is not helping the callers code density. So the only objective that might be furthered here is stdarg callee simplicity. But if you really want that, and ignore compatibility with broken code, the logical thing to do is not to pass any unnamed arguments in registers. If stdarg caller's code size is considered important, and stdarg callees mostly irrelevant (as mostly associated with I/O, and linked in just once per function), this aligns well with supporting broken code: it shouldn't matter if the argument is anonymous or not, it's the same effort for the caller to pass it. One further thing to consider when forging new ABIs is that partial argument passing is there solely for the convenience of stdarg callees, and/or the programmer who wrote that part of the t
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
First, I will split this patch in two. The first part will deal with the FPU instructions. The second patch, will try to address a new abi optimized for odd-even registers as the comments for the mabi=optimized are numerous and I need to carefully prepare for an answer. The remaining of this email will focus on FPU patch. > + case EQ: > + case NE: > + case UNORDERED: > + case UNLT: > + case UNLE: > + case UNGT: > + case UNGE: > + return CC_FPUmode; > + > + case LT: > + case LE: > + case GT: > + case GE: > + case ORDERED: > + return CC_FPUEmode; > > cse and other code transformations are likely to do better if you use > just one mode for these. It is also very odd to have comparisons and their > inverse use different modes. Have you done any benchmarking for this? Right, the ORDERED should be in CC_FPUmode. An inspiration point for CC_FPU/CC_FPUE mode is the arm port. The reason why having the two CC_FPU and CC_FPUE modes is to emit signaling FPU compare instructions. We can use a single CC_FPU mode here instead of two, but we may lose functionality. Regarding benchmarks, I do not have an establish benchmark for this, however, as far as I could see the code generated for FPU looks clean. Please let me know if it is acceptable to go with CC_FPU/CC_FPUE, and ORDERED fix further on. Or, to have a single mode. > + /* 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. Although, I haven't bump into this issue until now, I do not say it may not happen. Hence, I would create a new register class to hold the odd-even registers. Hence the above code will not be needed. What do u say? > still in "subdf3": > + else if (TARGET_FP_DOUBLE) > > So this implies that both (TARGET_DPFP) and (TARGET_FP_DOUBLE) might > be > true at > the same time. In that case, so we really want to prefer the > (TARGET_DPFP) expansion? The TARGET_DPFP (FPX instructions) and TARGET_FP_DOUBLE (FPU) are mutually exclusive. It should be a check in arc_init() function for this case. > +(define_insn "*cmpsf_trap_fpu" > > That name makes as little sense to me as having two separate modes > CC_FPU and CC_FPUE > for positive / negated usage and having two comparison patterns pre > precision that > do the same but pretend to be dissimilar. > The F{S/D}CMPF instruction is similar to the F{S/D}CMP instruction in cases when either of the instruction operands is a signaling NaN. The FxCMPF instruction updates the invalid flag (FPU_STATUS.IV) when either of the operands is a quiet or signaling NaN, whereas, the FxCMP instruction updates the invalid flag (FPU_STATUS.IV) only when either of the operands is a quiet NaN. We need to use the FxCMPF only if we keep the CC_FPU an CC_FPUE otherwise, we shall use only FxCMP instruction. > Also, the agglomeration of S/D with FU{S,Z}ED is confusing. Could you > spare another underscore? Is this better? #define TARGET_FP_SP_BASE ((arc_fpu_build & FPU_SP) != 0) #define TARGET_FP_DP_BASE ((arc_fpu_build & FPU_DP) != 0) #define TARGET_FP_SP_FUSED ((arc_fpu_build & FPU_SF) != 0) #define TARGET_FP_DP_FUSED ((arc_fpu_build & FPU_DF) != 0) #define TARGET_FP_SP_CONV ((arc_fpu_build & FPU_SC) != 0) #define TARGET_FP_DP_CONV ((arc_fpu_build & FPU_DC) != 0) #define TARGET_FP_SP_SQRT ((arc_fpu_build & FPU_SD) != 0) #define TARGET_FP_DP_SQRT ((arc_fpu_build & FPU_DD) != 0) #define TARGET_FP_DP_AX ((arc_fpu_build & FPX_DP) != 0) Thanks, Claudiu
Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.
On 03/02/16 15:02, Claudiu Zissulescu wrote: First, I will split this patch in two. The first part will deal with the FPU instructions. The second patch, will try to address a new abi optimized for odd-even registers as the comments for the mabi=optimized are numerous and I need to carefully prepare for an answer. The remaining of this email will focus on FPU patch. + case EQ: + case NE: + case UNORDERED: + case UNLT: + case UNLE: + case UNGT: + case UNGE: + return CC_FPUmode; + + case LT: + case LE: + case GT: + case GE: + case ORDERED: + return CC_FPUEmode; cse and other code transformations are likely to do better if you use just one mode for these. It is also very odd to have comparisons and their inverse use different modes. Have you done any benchmarking for this? Right, the ORDERED should be in CC_FPUmode. An inspiration point for CC_FPU/CC_FPUE mode is the arm port. I can't see how this code in the arm can actually work correctly. When, for instance, combine simplifies a comparison, the comparison code can change, and it will use SELECT_CC_MODE to find a new mode for the comparison. Thus, if a comparison traps or not on qNaNs will depend on the whims of combine. Also, the the trapping comparisons don't show the side effect of trapping on qNaNs, which means they can be speculated. To make the trapping comparisons safe, they should display the side effect in the rtl, and only be used when requested by options, type attributes, pragmas etc. They could almost be safe to use be default for -ffinite-math-only, except that when the frontend knows how to tell qNaNs and sNaNs apart, and speculates a comparison after some integer/fp mixed computation when it can infer that no sNaN will occur, you could still get an unexpected signal. The reason why having the two CC_FPU and CC_FPUE modes is to emit signaling FPU compare instructions. I don't know if your compare instructions are signalling for quiet NaNs (I hope they're not), but the mode of the comparison result shouldn't be used to distinguish that - it's not safe, see above. The purpose of the mode of the result is to distinguish different interpretations for the bit patterns inside the comparison result flags. We can use a single CC_FPU mode here instead of two, but we may lose functionality. Can you define what that functionality actually is, and show some simple test code to demonstrate how it works with your port extension? Regarding benchmarks, I do not have an establish benchmark for this, however, as far as I could see the code generated for FPU looks clean. Please let me know if it is acceptable to go with CC_FPU/CC_FPUE, and ORDERED fix further on. No, there should be a discernible and achievable purpose for comparison modes. Which you have not demonstrated yet so far for the CC_FPU/CC_FPUE dichotomy. Or, to have a single mode. Yes. + /* 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. Although, I haven't bump into this issue until now, I do not say it may not happen. Hence, I would create a new register class to hold the odd-even registers. Hence the above code will not be needed. What do u say? That would have been possible a couple of years ago, but these days, all the constituent registers of a multi-reg hard register have to be in a constraint's register class for the constraint to match. You could fudge this by using two classes for two-reg allocations, one with 0,1, 4,5, 8,9 ... the other with 2,3, 6,7, 10,11 ... , but then you need another pair for four-register allocations, and maybe you want to add various union and intersection classes, and the register allocators are rather rubbis when it comes to balance allocations between classes of similar size and utility, so you should really try to avoid this. A way to avoid this is not to give the option of using the old ABI while enforcing alignment in registers. Or you could use a different mode for the argument passing when it ends up unaligned; I suppose BLKmode should work, using a vector to designate the constituent registers of the function argument. +(define_insn "*cmpsf_trap_fpu" That name makes as little sense to me as having two separate modes CC_FPU and CC_FPUE for positive / negated usage and having two comparison patterns pre precision that do the same but pretend to be dissimilar. The F{S/D}CMPF instruction is similar to the F{S/D}CMP instruction Oops. I missed the 'f' suffix. So the "*trap_fpu" patterns really are different... in cases when either of the instruction opera
Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.
P.S.: if code that is missing prototypes for stdarg functions is of no concern, there is another ABI alternative that might give good code density for architectures like ARC that have pre-decrement addressing modes and allow immediates to be pushed: You could put all unnamed arguments on the stack (thus simplifying varargs processing), and leave all registers not used for argument passing call-saved. Thus, the callers wouldn't have to worry about saving these registers or reloading their values from the stack. For gcc, this would require making the call fusage really work - probably involving a hook to tell the middle-end that the port really wants that - or a kludge to make affected call insn not look like call insns, similar to the sfuncs.
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
> P.S.: if code that is missing prototypes for stdarg functions is of no > concern, > there is another ABI alternative that might give good code density for > architectures like ARC that have pre-decrement addressing modes and allow > immediates to be pushed: > > You could put all unnamed arguments on the stack (thus simplifying varargs > processing), and leave all registers not used for argument passing call-saved. > Thus, the callers wouldn't have to worry about saving these registers or > reloading their values from the stack. > > For gcc, this would require making the call fusage really work - probably > involving a hook to tell the middle-end that the port really wants that - or a > kludge to make affected call insn not look like call insns, similar to the > sfuncs. Unfortunately, we need to be compatible with the previous ABI for the time being. I am now investigating passing the DI like modes in non even-odd registers. The biggest challenge is how to pass such a mode partially, without introducing odd/even register classes.
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
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 0001-ARC-Add-single-double-IEEE-precission-FPU-support.patch Description: 0001-ARC-Add-single-double-IEEE-precission-FPU-support.patch
Re: [PATCH] [ARC] Add single/double IEEE precission FPU support.
On 09/02/16 15:34, Claudiu Zissulescu wrote: 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 That sound like a bug. Have you looked more closely what's going on?
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
> > 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 > > That sound like a bug. Have you looked more closely what's going on? The fwprop1 is collapsing insn 20 into insn 21. No surprise until here. Then, the combiner is changing first insn 19 and 21 into insn 21 (this seems sane). Followed by combining the resulted insn 21 into insn 22. Finally, insn 22 is changing the condition of the jump (insn 22). The last steps are a bit too aggressive, but I can make a logic out of it. Practically, insn 22 tells to the combiner how to change a CC_FPU mode into a CC_ZN mode, resulting into the modification of insn 21 to insn23. However, I cannot understand why the combiner chooses for CC_ZN instead of CC_FPU
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
> That sound like a bug. Have you looked more closely what's going on? Right, I found it. Forgot to set the C_MODE for CC_FPU* modes in the arc_mode_class[]. I will prepare a new patch with the proper handling. Thanks!
RE: [PATCH] [ARC] Add single/double IEEE precission FPU support.
Please find attached the amended patch for FPU instructions. Ok to apply? 0001-ARC-Add-single-double-IEEE-precission-FPU-support.patch Description: 0001-ARC-Add-single-double-IEEE-precission-FPU-support.patch