RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-12-02 16:36:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
6333fd2b12
llvm-mirror/test/CodeGen/Mips/nomips16.ll

39 lines
1.4 KiB
LLVM
Raw Normal View History

[Mips] Adjust float ABI settings in case of MIPS16 mode. Hard float for mips16 means essentially to compile as soft float but to use a runtime library for soft float that is written with native mips32 floating point instructions (those runtime routines run in mips32 hard float mode). The patch reviewed by Reed Kotler. llvm-svn: 195123
2013-11-19 12:20:17 +00:00
; RUN: llc -mtriple=mipsel-linux-gnu -march=mipsel -mcpu=mips16 -relocation-model=static < %s | FileCheck %s
Fix a problem with dual mips16/mips32 mode. When the underlying processor has hard float, when you compile the mips32 code you have to make sure that it knows to compile any mips32 routines as hard float. I need to clean up the way mips16 hard float is specified but I need to first think through all the details. Mips16 always has a form of soft float, the difference being whether the underlying hardware has floating point. So it's not really necessary to pass the -soft-float to llvm since soft-float is always true for mips16 by virtue of the fact that it will not register floating point registers. By using this fact, I can simplify the way this is all handled. llvm-svn: 189690
2013-08-30 19:40:56 +00:00
@x = global float 0.000000e+00, align 4
@.str = private unnamed_addr constant [20 x i8] c"in main: mips16 %f\0A\00", align 1
; Function Attrs: nounwind
define void @foo() #0 {
entry:
%0 = load float* @x, align 4
%conv = fpext float %0 to double
%add = fadd double %conv, 1.500000e+00
%conv1 = fptrunc double %add to float
store float %conv1, float* @x, align 4
ret void
}
; CHECK: .ent foo
; CHECK: jal __mips16_extendsfdf2
; CHECK: .end foo
; Function Attrs: nounwind
define void @nofoo() #1 {
entry:
%0 = load float* @x, align 4
%conv = fpext float %0 to double
%add = fadd double %conv, 3.900000e+00
%conv1 = fptrunc double %add to float
store float %conv1, float* @x, align 4
ret void
}
; CHECK: .ent nofoo
; CHECK: cvt.d.s $f{{.+}}, $f{{.+}}
; CHECK: .end nofoo
Add the first backend support for on demand subtarget creation based on the Function. This is currently used to implement mips16 support in the mips backend via the existing module pass resetting the subtarget. Things to note: a) This involved running resetTargetOptions before creating a new subtarget so that code generation options like soft-float could be recognized when creating the new subtarget. This is to deal with initialization code in isel lowering that only paid attention to the initial value. b) Many of the existing testcases weren't using the soft-float feature correctly. I've corrected these based on the check values assuming that was the desired behavior. c) The mips port now pays attention to the target-cpu and target-features strings when generating code for a particular function. I've removed these from one function where the requested cpu and features didn't match the check lines in the testcase. llvm-svn: 218492
2014-09-26 01:44:08 +00:00
attributes #0 = { nounwind "less-precise-fpmad"="false" "mips16" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "nomips16" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
Fix a problem with dual mips16/mips32 mode. When the underlying processor has hard float, when you compile the mips32 code you have to make sure that it knows to compile any mips32 routines as hard float. I need to clean up the way mips16 hard float is specified but I need to first think through all the details. Mips16 always has a form of soft float, the difference being whether the underlying hardware has floating point. So it's not really necessary to pass the -soft-float to llvm since soft-float is always true for mips16 by virtue of the fact that it will not register floating point registers. By using this fact, I can simplify the way this is all handled. llvm-svn: 189690
2013-08-30 19:40:56 +00:00
Reference in New Issue Copy Permalink