This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb


Ah, light dawns (maybe).

I guess the problems stem from the attempts to combine Neon with ARMv5.
 Neon shouldn't be used with anything prior to ARMv7, since that's the
earliest version of the architecture that can support it.

I guess that what is happening is that we see we have Neon, so start to
generate a Neon-based copy sequence, but then notice that we don't have
misaligned access (something that must exist if we have Neon) and
generate VLDR instructions in a mistaken attempt to work around the
first inconsistency.

Maybe we should tie -mfpu=neon to having at least ARMv7 (though ARMv6
also has misaligned access support).

R.

On 28/05/14 00:03, Maciej W. Rozycki wrote:
> On Tue, 27 May 2014, Kyrill Tkachov wrote:
> 
>>>>   This change however has regressed gcc.dg/vect/vect-72.c on the
>>>> arm-linux-gnueabi target, -march=armv5te, in particular in 4.8.
>>> And what are all the configure flags you are using in case some one
>>> has to reproduce this issue ?
>>
>> Second that. My recently built 4.8 (gcc version 4.8.2 20130531) for vect-72
>> with options:
>>  -O2 -ftree-vectorize -march=armv5te -mfpu=neon -mfloat-abi=hard
>> -fno-vect-cost-model -fno-common
>>
>> gives code the same as your original one:
>> .L14:
>>         sub     r1, r3, #16
>>         add     r3, r3, #16
>>         vld1.8  {q8}, [r1]
>>         cmp     r3, r0
>>         vst1.64 {d16-d17}, [r2:64]!
>>         bne     .L14
>>         ldr     r3, .L22+12
>>         add     ip, r3, #128
>>         add     r2, r3, #129
> 
>  I have this:
> 
> .L14:
> 	sub	r1, r3, #16	@ 130	*arm_addsi3/7	[length = 4]
> 	add	r3, r3, #16	@ 135	*arm_addsi3/2	[length = 4]
> 	vld1.8	{q8}, [r1]	@ 131	*movmisalignv16qi_neon_load	[length = 4]
> 	cmp	r3, r0	@ 136	*arm_cmpsi_insn/3	[length = 4]
> 	vst1.64	{d16-d17}, [r2:64]!	@ 133	*neon_movv16qi/2	[length = 8]
> 	bne	.L14	@ 137	arm_cond_branch	[length = 4]
> 
> without and this:
> 
> .L14:
> 	vldr	d16, [r3, #-16]	@ 130	*neon_movv16qi/4	[length = 8]
> 	vldr	d17, [r3, #-8]
> 	add	r3, r3, #16	@ 133	*arm_addsi3/2	[length = 4]
> 	cmp	r3, r1	@ 134	*arm_cmpsi_insn/3	[length = 4]
> 	vst1.64	{d16-d17}, [r2:64]!	@ 131	*neon_movv16qi/2	[length = 8]
> 	bne	.L14	@ 135	arm_cond_branch	[length = 4]
> 
> with your change applied respectively so clearly it's making its intended 
> effect of disabling the use of movmisalignv16qi_neon_load.
> 
>  However VLD1.8 can also be produced from other RTL patterns, or maybe you 
> don't have `unaligned_access' set to zero for some reason, which you 
> should (for ARMv5TE) according to this gcc/config/arm/arm.c piece:
> 
>   /* Enable -munaligned-access by default for
>      - all ARMv6 architecture-based processors
>      - ARMv7-A, ARMv7-R, and ARMv7-M architecture-based processors.
>      - ARMv8 architecture-base processors.
> 
>      Disable -munaligned-access by default for
>      - all pre-ARMv6 architecture-based processors
>      - ARMv6-M architecture-based processors.  */
> 
>   if (unaligned_access == 2)
>     {
>       if (arm_arch6 && (arm_arch_notm || arm_arch7))
> 	unaligned_access = 1;
>       else
> 	unaligned_access = 0;
>     }
>   else if (unaligned_access == 1
> 	   && !(arm_arch6 && (arm_arch_notm || arm_arch7)))
>     {
>       warning (0, "target CPU does not support unaligned accesses");
>       unaligned_access = 0;
>     }
> 
> -- can you build vect-72.c with -dp and see which pattern VLD1.8 is 
> produced from in your case?
> 
>  As to the GCC configure options I have as I say nothing there beyond 
> making -march=armv5te the default (surely you're not interested in 
> --prefix, etc.).  For the record the test framework adds these options on 
> top of that for this particular case:
> 
> -fno-diagnostics-show-caret -mfpu=neon -mfloat-abi=softfp -ffast-math 
> -ftree-vectorize -fno-vect-cost-model -fno-common -O2 
> -fdump-tree-vect-details
> 
> but these should be no different in your case (except perhaps from 
> `-mfloat-abi=', but that shouldn't matter as this is no FP code).
> 
>  I have double-checked with current (r210984) 4.8 now and the issue is 
> still there.
> 
>   Maciej
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]