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