[patch RFA] SH: Fix build failure for sh64-*-linux-gnu

[Joern RENNECKE]

Kaz Kojima wrote:

>  
>+/* The `Cpi' constraint is a symbolic constant for PIC.  */
>+#define EXTRA_CONSTRAINT_Cpi(OP) \
>+  MOVI_SHORI_BASE_OPERAND_P ((OP))
>  
>
This is not actually specific for PIC.  Neither does it seem necessary...

>  (define_insn "shori_media"
>-  [(set (match_operand:DI 0 "ext_dest_operand" "=r,r")
>-	(ior:DI (ashift:DI (match_operand:DI 1 "arith_reg_operand" "0,0")
>+  [(set (match_operand:DI 0 "ext_dest_operand" "=r,r,r")
>+	(ior:DI (ashift:DI (match_operand:DI 1 "arith_reg_operand" "0,0,0")
> 			   (const_int 16))
> 		(zero_extend:DI
> 		 (truncate:HI
>-		  (match_operand:DI 2 "immediate_operand" "I16C16,nF")))))]
>+		  (match_operand:DI 2 "immediate_operand" "I16C16,Cpi,nF")))))]
>   "TARGET_SHMEDIA && (reload_completed || arith_reg_dest (operands[0], DImode))"
>   "@
> 	shori	%u2, %0
>+	shori	((%u2) & 65535), %0
> 	#"
>-  [(set_attr "type" "arith_media,*")])
>+  [(set_attr "type" "arith_media,arith_media,*")])
>  
>

... since you can you 's' for the constraint.  (In principle 'i' should 
work as well, but
we shouldn't be generating out-of-range numeric constants in the first 
place.)

It also seems prudent to remove the generation of the sign_extend / 
truncate steps
from gen_movsi_const / gen_movdi_const / gen_movdi_const_32bit .

> @@ -8325,7 +8328,12 @@ label:
>   ""
>   "
> {
>-  emit_insn (gen_symGOT_load (operands[0], gen_sym2GOTPLT (operands[1])));
>+  rtx pltsym;
>+
>+  pltsym = gen_sym2GOTPLT (operands[1]);
>+  PUT_MODE (pltsym, Pmode);
>+  emit_insn (gen_symGOT_load (operands[0], pltsym));
>+
>   DONE;
> }")
> 
>  
>
I don't see why this is connected to the extend/truncate elimination.  
Do we actually
end up assuming the value is smaller than it is, and thus won't do the 
transformation
when we know the actual size?

In general, it is desirable (and often necessary) to have a mode on 
every const and unspec
used for a data item (I mean an actual rtl data item - matching patterns 
often have to leave
out the mode).  We don't always do this because of the awkwardness of 
putting
Pmode in an expander.  Still, I would prefer to fix this in the 
sym2GOTPLT expander -
I suppose the only sane way to do this is making it a C function.  
You'll will have to watch
out if this disrupts any insn, combiner/splitter or peephole patterns, 
though.