RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-24 21:42:54 +02:00
Code Issues Projects Releases Wiki Activity
48c7ec9aa0
llvm-mirror/test/CodeGen/Mips/abiflags32.ll

18 lines
794 B
LLVM
Raw Normal View History

Mips.abiflags is a new implicitly generated section that will be present on all new modules. The section contains a versioned data structure which represents essentially information to allow a program loader to determine the requirements of the application. This patch implements mips.abiflags section and provides test cases for it. llvm-svn: 212519
2014-07-08 10:59:22 +02:00
; RUN: llc -filetype=asm -mtriple mipsel-unknown-linux -mcpu=mips32 %s -o - | FileCheck %s
; RUN: llc -filetype=asm -mtriple mipsel-unknown-linux -mcpu=mips32 -mattr=fp64 %s -o - | FileCheck -check-prefix=CHECK-64 %s
Move the Mips target to storing the ABI in the TargetMachine rather than on MipsSubtargetInfo. This required a bit of massaging in the MC level to handle this since MC is a) largely a collection of disparate classes with no hierarchy, and b) there's no overarching equivalent to the TargetMachine, instead only the subtarget via MCSubtargetInfo (which is the base class of TargetSubtargetInfo). We're now storing the ABI in both the TargetMachine level and in the MC level because the AsmParser and the TargetStreamer both need to know what ABI we have to parse assembly and emit objects. The target streamer has a pointer to the one in the asm parser and is updated when the asm parser is created. This is fragile as the FIXME comment notes, but shouldn't be a problem in practice since we always create an asm parser before attempting to emit object code via the assembler. The TargetMachine now contains the ABI so that the DataLayout can be constructed dependent upon ABI. All testcases have been updated to use the -target-abi command line flag so that we can set the ABI without using a subtarget feature. Should be no change visible externally here. llvm-svn: 227102
2015-01-26 18:33:46 +01:00
; RUN: llc -filetype=asm -mtriple mipsel-unknown-linux -mcpu=mips64 -target-abi n32 %s -o - | FileCheck -check-prefix=CHECK-64n %s
Mips.abiflags is a new implicitly generated section that will be present on all new modules. The section contains a versioned data structure which represents essentially information to allow a program loader to determine the requirements of the application. This patch implements mips.abiflags section and provides test cases for it. llvm-svn: 212519
2014-07-08 10:59:22 +02:00
; CHECK: .nan legacy
[mips] Do not emit '.module fp=...' unless we really need to. We now emit this value when we need to contradict the default value. This restores support for binutils 2.24. When a suitable binutils has been released we can resume unconditionally emitting .module directives. This is preferable to omitting the .module directives since the .module directives protect against, for example, accidentally assembling FP32 code with -mfp64 and producing an unusuable object. llvm-svn: 213548
2014-07-21 17:25:24 +02:00
; We don't emit '.module fp=32' for compatibility with binutils 2.24 which
; doesn't accept .module.
; CHECK-NOT: .module fp=32
Mips.abiflags is a new implicitly generated section that will be present on all new modules. The section contains a versioned data structure which represents essentially information to allow a program loader to determine the requirements of the application. This patch implements mips.abiflags section and provides test cases for it. llvm-svn: 212519
2014-07-08 10:59:22 +02:00
; CHECK-64: .nan legacy
[mips] Do not emit '.module fp=...' unless we really need to. We now emit this value when we need to contradict the default value. This restores support for binutils 2.24. When a suitable binutils has been released we can resume unconditionally emitting .module directives. This is preferable to omitting the .module directives since the .module directives protect against, for example, accidentally assembling FP32 code with -mfp64 and producing an unusuable object. llvm-svn: 213548
2014-07-21 17:25:24 +02:00
; We do emit '.module fp=64' though since it contradicts the default value.
Mips.abiflags is a new implicitly generated section that will be present on all new modules. The section contains a versioned data structure which represents essentially information to allow a program loader to determine the requirements of the application. This patch implements mips.abiflags section and provides test cases for it. llvm-svn: 212519
2014-07-08 10:59:22 +02:00
; CHECK-64: .module fp=64
; CHECK-64n: .nan legacy
[mips] Do not emit '.module fp=...' unless we really need to. We now emit this value when we need to contradict the default value. This restores support for binutils 2.24. When a suitable binutils has been released we can resume unconditionally emitting .module directives. This is preferable to omitting the .module directives since the .module directives protect against, for example, accidentally assembling FP32 code with -mfp64 and producing an unusuable object. llvm-svn: 213548
2014-07-21 17:25:24 +02:00
; We don't emit '.module fp=64' for compatibility with binutils 2.24 which
; doesn't accept .module.
; CHECK-64n-NOT: .module fp=64
Reference in New Issue Copy Permalink