On Tue, Aug 1, 2017 at 12:51 PM, Tamar Christina
wrote:
>>
>> Given review comment already pointed out big-endian issue and patch was
>> updated to address it, I would expect reg-test on a big-endian target before
>> applying patch, right?
>
> The patch spent 6 months in
gt; (movi-split-hf-df-sf split, fp16): New.
> > (enabled): Added TARGET_FP_F16INST.
> > * config/aarch64/iterators.md (GPF_HF): New.
> >
> > From: Tamar Christina
> > Sent: Wednesday, June 21, 2017 11:48:33 A
t, fp16): New.
> (enabled): Added TARGET_FP_F16INST.
> * config/aarch64/iterators.md (GPF_HF): New.
>
> From: Tamar Christina
> Sent: Wednesday, June 21, 2017 11:48:33 AM
> To: James Greenhalgh
> Cc: GCC Patches; nd; Marcus Shawcrof
On Mon, Jun 26, 2017 at 11:50:51AM +0100, Tamar Christina wrote:
> Hi all,
>
> Here's the re-spun patch.
> Aside from the grouping of the split patterns it now also uses h register for
> the fmov for HF when available,
> otherwise it forces a literal load.
>
> Regression tested on
Ping
From: Tamar Christina
Sent: Monday, July 3, 2017 7:12:05 AM
To: James Greenhalgh
Cc: GCC Patches; nd; Marcus Shawcroft; Richard Earnshaw
Subject: Re: [PATCH][GCC][AArch64] optimize float immediate moves (2 /4) -
HF/DF/SF mode.
Ping
17 11:48:33 AM
To: James Greenhalgh
Cc: GCC Patches; nd; Marcus Shawcroft; Richard Earnshaw
Subject: RE: [PATCH][GCC][AArch64] optimize float immediate moves (2 /4) -
HF/DF/SF mode.
> > movi\\t%0.4h, #0
> > - mov\\t%0.h[0], %w1
> > + fmov\\t%s0, %w1
>
> Should this not b
: RE: [PATCH][GCC][AArch64] optimize float immediate moves (2 /4) -
HF/DF/SF mode.
> > movi\\t%0.4h, #0
> > - mov\\t%0.h[0], %w1
> > + fmov\\t%s0, %w1
>
> Should this not be %h0?
The problem is that H registers are only available in ARMv8.2+,
I'm not sure what
> > movi\\t%0.4h, #0
> > - mov\\t%0.h[0], %w1
> > + fmov\\t%s0, %w1
>
> Should this not be %h0?
The problem is that H registers are only available in ARMv8.2+,
I'm not sure what to do about ARMv8.1 given your other feedback
Pointing out that the bit patterns between how it's stored in s
>
> It doesn't need to, because all HImode CONST_INTs are already legitimate.
> You can just use emit_move_insn instead.
>
Ah right, that's true.
> FWIW, the following seems to pass the same tests and avoids the subreg
> dance. Just a proof of concept, and I'm not attached to the new iterator
Tamar Christina writes:
> Hi Richard,
>> > > +rtx tmp = gen_reg_rtx (SImode);
>> > > +aarch64_expand_mov_immediate (tmp, gen_int_mode (ival,
>> SImode));
>> > > +tmp = simplify_gen_subreg (HImode, tmp, SImode, 0);
>> >
>> > This looks wrong for big-endian,
Hi Richard,
> > > +rtx tmp = gen_reg_rtx (SImode);
> > > +aarch64_expand_mov_immediate (tmp, gen_int_mode (ival,
> SImode));
> > > +tmp = simplify_gen_subreg (HImode, tmp, SImode, 0);
> >
> > This looks wrong for big-endian, and...
> >
> > > +emit_move_insn (operands[0],
Hi Richard,
> > +rtx tmp = gen_reg_rtx (SImode);
> > +aarch64_expand_mov_immediate (tmp, gen_int_mode (ival, SImode));
> > +tmp = simplify_gen_subreg (HImode, tmp, SImode, 0);
>
> This looks wrong for big-endian, and...
>
> > +emit_move_insn (operands[0], gen_lowpart (HFmode,
In addition to James's comments:
Tamar Christina writes:
> + [(const_int 0)]
> + "{
"{ ... }" isn't necessary, we can just use { ... }
> +unsigned HOST_WIDE_INT ival;
> +if (!aarch64_reinterpret_float_as_int (operands[1], ))
> + FAIL;
> +
> +rtx tmp
On Wed, Jun 07, 2017 at 12:38:37PM +0100, Tamar Christina wrote:
> Hi All,
>
>
> This patch adds support for creating floating point constants
> using mov immediate instructions. The movi SIMD instruction can
> be used for HFmode and SFmode constants, eg. for -0.0f we generate:
>
>
Hi All,
Updating this patch with the feedback I've received from patch 1/4.
Thanks,
Tamar
From: gcc-patches-ow...@gcc.gnu.org on behalf
of Tamar Christina
Sent: Wednesday, June 7, 2017 12:38:37 PM
15 matches
Mail list logo