[PATCH, x86_64]: Fix PR target/31167

Jan Hubicka hubicka@ucw.cz
Thu Mar 15 00:45:00 GMT 2007


> Hello!
> 
> The problem, exposed by the testcase in the bugreport, is with TImode 
> addti3_1 pattern and its splitter. Same problems can be expected with 
> subti3_1, negti2_1 and their splitters.
> 
> The core of the problem is in splitter, where we split TImode immediate 
> into two DImode immediates. Unfortunatelly, 64bit instructions can 
> accept only 32bit immediates.
> 
> The solution is straightforward. As TImode immediates can't be split 
> into two legal DImode values, we reject all but 32bit type "e" immediate 
> values for affected TImode patterns.

Either this, or we can implement constraint letter matching only 128bit
constants that can be split into two to 64bit sign extended 32bit
constants, but I guess it is not worth the effort.
> 
> Patch is bootstrapped on x86_64-pc-linux-gnu, regression tested for all 
> default languages. As this patch is pure x86_64 stuff, it needs a x86_64 
> maintainer approval.

My understanding is that x86_64 is subtarget of i386 backend, so i386
maintaner can approve x86_64 patches (ie to config/i386 directory).

> @@ -9684,7 +9684,7 @@
>  
>  (define_insn "*negti2_1"
>    [(set (match_operand:TI 0 "nonimmediate_operand" "=ro")
> -	(neg:TI (match_operand:TI 1 "general_operand" "0")))
> +	(neg:TI (match_operand:TI 1 "x86_64_general_operand" "0")))
>     (clobber (reg:CC FLAGS_REG))]
>    "TARGET_64BIT
>     && ix86_unary_operator_ok (NEG, TImode, operands)"
> @@ -9692,7 +9692,7 @@
>  
>  (define_split
>    [(set (match_operand:TI 0 "nonimmediate_operand" "")
> -	(neg:TI (match_operand:TI 1 "general_operand" "")))
> +	(neg:TI (match_operand:TI 1 "x86_64_general_operand" "")))

It seems that nonimmediate_operand is better match in both cases here,
especially because of the matching constraint string above.

Honza
>     (clobber (reg:CC FLAGS_REG))]
>    "TARGET_64BIT && reload_completed"
>    [(parallel



More information about the Gcc-patches mailing list