On Thu, Nov 13, 2014 at 3:20 PM, Yangfei (Felix) <felix.y...@huawei.com> wrote:
>> >> > Just curious about this. Can we make sure that FPAdvSIMD are
>> >> > always
>> >> enabled?
>> >> >
>> >>
>> >> I am not sure I understand correct, do you mean enable options like
>> >> below default?
>> >> --with-fpu=crypto-neon-fp-armv8/--with-float=hard
>> >>
>> >> Thanks,
>> >> bin
>> >
>> >
>> > I mean the NEON hardware. The processor checks if the FPAdvSIMD is
>> enabled when executing an NEON instruction.
>> >
>> > aarch64/exceptions/traps/functions/AArch64.CheckFPAdvSIMDEnabled
>> > // AArch64.CheckFPAdvSIMDEnabled()
>> > // ===============================
>> > // Check against CPACR_EL1.
>> > AArch64.CheckFPAdvSIMDEnabled()
>> > if PSTATE.EL IN {EL0, EL1} then
>> > // Check if access disabled in CPACR_EL1 case CPACR_EL1.FPEN of when
>> > 'x0' disabled = TRUE; when '01' disabled = PSTATE.EL == EL0; when '11'
>> > disabled = FALSE; if disabled then AArch64.AdvSIMDFPAccessTrap(EL1);
>> > AArch64.CheckFPAdvSIMDTrap(); // Also check against CPTR_EL2 and
>> > CPTR_EL3
>> >
>>
>> Oh, this is a question that compiler/software engineers don't have the
>> answer.
>> Also it's inappropriate for gcc mailing list. Sorry.
>>
>> Thanks,
>> bin
>
>
> But what if the compiler generates NEON instructions for stringops when the
> NEON hardware is disabled?
> So this kind of optimizations depend on the command line option such as
> --with-float=hard, right?
Yes, see arm.c/arm.h, neon instructions in this case are only
generated when TARGET_NEON is true (and some other conditions), which
is defined as below.
#define TARGET_NEON (TARGET_32BIT && TARGET_HARD_FLOAT \
&& TARGET_VFP && arm_fpu_desc->neon)
Thanks,
bin
