m
> 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"
>
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
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
> 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!
> > 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_FP
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
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 (
> 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 argumen
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 st
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
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 ema
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
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
13 matches
Mail list logo
