Prepare to make r0 an allocatable register on PPC
Currently the PPC r0 register is unconditionally reserved. There are two reasons
for this:
1. r0 is treated specially (as the constant 0) by certain instructions, and so
cannot be used with those instructions as a regular register.
2. r0 is used as a temporary register in the CR-register spilling process
(where, under some circumstances, we require two GPRs).
This change addresses the first reason by introducing a restricted register
class (without r0) for use by those instructions that treat r0 specially. These
register classes have a new pseudo-register, ZERO, which represents the r0-as-0
use. This has the side benefit of making the existing target code simpler (and
easier to understand), and will make it clear to the register allocator that
uses of r0 as 0 don't conflict will real uses of the r0 register.
Once the CR spilling code is improved, we'll be able to allocate r0.
Adding these extra register classes, for some reason unclear to me, causes
requests to the target to copy 32-bit registers to 64-bit registers. The
resulting code seems correct (and causes no test-suite failures), and the new
test case covers this new kind of asymmetric copy.
As r0 is still reserved, no functionality change intended.
llvm-svn: 177423
2013-03-20 02:51:05 +08:00
|
|
|
; RUN: llc < %s -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr7
|
|
|
|
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
|
|
|
|
target triple = "powerpc64-unknown-linux-gnu"
|
|
|
|
|
2013-03-22 07:23:34 +08:00
|
|
|
; This tests that the GPRC/GPRC_NOR0 intersection subclass relationship with
|
|
|
|
; GPRC is handled correctly. When it was not, this test would assert.
|
2013-03-20 04:22:32 +08:00
|
|
|
|
Prepare to make r0 an allocatable register on PPC
Currently the PPC r0 register is unconditionally reserved. There are two reasons
for this:
1. r0 is treated specially (as the constant 0) by certain instructions, and so
cannot be used with those instructions as a regular register.
2. r0 is used as a temporary register in the CR-register spilling process
(where, under some circumstances, we require two GPRs).
This change addresses the first reason by introducing a restricted register
class (without r0) for use by those instructions that treat r0 specially. These
register classes have a new pseudo-register, ZERO, which represents the r0-as-0
use. This has the side benefit of making the existing target code simpler (and
easier to understand), and will make it clear to the register allocator that
uses of r0 as 0 don't conflict will real uses of the r0 register.
Once the CR spilling code is improved, we'll be able to allocate r0.
Adding these extra register classes, for some reason unclear to me, causes
requests to the target to copy 32-bit registers to 64-bit registers. The
resulting code seems correct (and causes no test-suite failures), and the new
test case covers this new kind of asymmetric copy.
As r0 is still reserved, no functionality change intended.
llvm-svn: 177423
2013-03-20 02:51:05 +08:00
|
|
|
@gen_random.last = external unnamed_addr global i64, align 8
|
|
|
|
@.str = external unnamed_addr constant [4 x i8], align 1
|
|
|
|
|
|
|
|
declare double @gen_random(double) #0
|
|
|
|
|
|
|
|
declare void @benchmark_heapsort(i32 signext, double* nocapture) #0
|
|
|
|
|
|
|
|
define signext i32 @main(i32 signext %argc, i8** nocapture %argv) #0 {
|
|
|
|
entry:
|
|
|
|
br i1 undef, label %cond.true, label %cond.end
|
|
|
|
|
|
|
|
cond.true: ; preds = %entry
|
|
|
|
br label %cond.end
|
|
|
|
|
|
|
|
cond.end: ; preds = %cond.true, %entry
|
|
|
|
%cond = phi i32 [ 0, %cond.true ], [ 8000000, %entry ]
|
|
|
|
%add = add i32 %cond, 1
|
|
|
|
%conv = sext i32 %add to i64
|
|
|
|
%mul = shl nsw i64 %conv, 3
|
|
|
|
%call1 = tail call noalias i8* @malloc(i64 %mul) #1
|
|
|
|
br i1 undef, label %for.end, label %for.body.lr.ph
|
|
|
|
|
|
|
|
for.body.lr.ph: ; preds = %cond.end
|
|
|
|
br label %for.body
|
|
|
|
|
|
|
|
for.body: ; preds = %for.body, %for.body.lr.ph
|
|
|
|
%indvars.iv = phi i64 [ 1, %for.body.lr.ph ], [ %indvars.iv.next, %for.body ]
|
|
|
|
%indvars.iv.next = add i64 %indvars.iv, 1
|
|
|
|
%lftr.wideiv = trunc i64 %indvars.iv.next to i32
|
|
|
|
%exitcond = icmp eq i32 %lftr.wideiv, %add
|
|
|
|
br i1 %exitcond, label %for.cond.for.end_crit_edge, label %for.body
|
|
|
|
|
|
|
|
for.cond.for.end_crit_edge: ; preds = %for.body
|
|
|
|
br label %for.end
|
|
|
|
|
|
|
|
for.end: ; preds = %for.cond.for.end_crit_edge, %cond.end
|
|
|
|
ret i32 0
|
|
|
|
}
|
|
|
|
|
|
|
|
declare noalias i8* @malloc(i64) #0
|
|
|
|
|
|
|
|
declare signext i32 @printf(i8* nocapture, ...) #0
|
|
|
|
|
|
|
|
declare void @free(i8* nocapture) #0
|
|
|
|
|
|
|
|
declare i64 @strtol(i8*, i8** nocapture, i32 signext) #0
|
|
|
|
|
2013-08-23 05:28:54 +08:00
|
|
|
attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }
|
Prepare to make r0 an allocatable register on PPC
Currently the PPC r0 register is unconditionally reserved. There are two reasons
for this:
1. r0 is treated specially (as the constant 0) by certain instructions, and so
cannot be used with those instructions as a regular register.
2. r0 is used as a temporary register in the CR-register spilling process
(where, under some circumstances, we require two GPRs).
This change addresses the first reason by introducing a restricted register
class (without r0) for use by those instructions that treat r0 specially. These
register classes have a new pseudo-register, ZERO, which represents the r0-as-0
use. This has the side benefit of making the existing target code simpler (and
easier to understand), and will make it clear to the register allocator that
uses of r0 as 0 don't conflict will real uses of the r0 register.
Once the CR spilling code is improved, we'll be able to allocate r0.
Adding these extra register classes, for some reason unclear to me, causes
requests to the target to copy 32-bit registers to 64-bit registers. The
resulting code seems correct (and causes no test-suite failures), and the new
test case covers this new kind of asymmetric copy.
As r0 is still reserved, no functionality change intended.
llvm-svn: 177423
2013-03-20 02:51:05 +08:00
|
|
|
attributes #1 = { nounwind }
|