[PATCH] ppc64 rs6000_emit_set_long_const improvements

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Jan 07, 2010 at 03:53:59AM -0500, Jakub Jelinek wrote:
> On Thu, Jan 07, 2010 at 09:48:53AM +0100, Gabriel Paubert wrote:
> > > apparently rs6000_emit_set_long_const needs work.
> > > 	lis 3,0x8034
> > > 	extsw 3,3
> > > or
> > > 	li 3,0x401a
> > > 	sldi 3,3,17
> > > etc. do IMHO the same.
> > 
> > Huh? I don't think so:
> > 
> > - first one loads 0xffff_ffff_8034_0000 in r3, and the extsw looks redundant
> 
> I meant lis 3,0x8034; rldicl 3,3,0,32 for the first case, sorry for mixing
> sign extension with zero extension.

Attached is a quick version of an optimization.

On:
long f0 (long x) { return 0x80340001UL; }
long f1 (long x) { return 0x80340000UL; }
long f2 (long x) { return 0xfffffff000000000UL; }
long f3 (long x) { return 0x1ffffffffUL; }
long f4 (long x) { return 0xffffff1230000000UL; }
long f5 (long x) { return 0x180340000UL; }
long f6 (long x) { return 0xfffffff180300000UL; }
the change is:
 .f0:
-	li 3,0
-	ori 3,3,32820
-	sldi 3,3,16
+	lis 3,0x8034
 	ori 3,3,1
+	rldicl 3,3,0,32
...
 .f1:
-	li 3,0
-	ori 3,3,32820
-	sldi 3,3,16
+	lis 3,0x8034
+	rldicl 3,3,0,32

Unfortunately the current constraints prohibit the other
easy constants (e.g. the 2 insns ones) from being expanded inline,
and the cases with just one 0->1 resp. 1->0 bit transition were already
handled before.  So, either we'd need to add a new constraint (for which
cases, just all 2 insn ones?), or it would be sufficient to kill
analyze_64bit_constant and just handle the ud3 == 0 && ud4 == 0 case.

	Jakub

Attachment: gcc45-ppc64-long-cst.patch
Description: Text document