summaryrefslogtreecommitdiff
path: root/tools/lto
diff options
context:
space:
mode:
authorJakob Stoklund Olesen <stoklund@2pi.dk>2014-01-14 06:18:38 +0000
committerJakob Stoklund Olesen <stoklund@2pi.dk>2014-01-14 06:18:38 +0000
commit5b8e04cd718a1b75bf129a6226c3d7212f29ab96 (patch)
treee1ed0d0ae836359bfbbafbd64a6613d061a8fc4a /tools/lto
parentaaf6cbdc7e368ebce35b95b9d596a739c7b234ff (diff)
downloadllvm-5b8e04cd718a1b75bf129a6226c3d7212f29ab96.tar.gz
llvm-5b8e04cd718a1b75bf129a6226c3d7212f29ab96.tar.bz2
llvm-5b8e04cd718a1b75bf129a6226c3d7212f29ab96.tar.xz
Always let value types influence register classes.
When creating a virtual register for a def, the value type should be used to pick the register class. If we only use the register class constraint on the instruction, we might pick a too large register class. Some registers can store values of different sizes. For example, the x86 xmm registers can hold f32, f64, and 128-bit vectors. The three different value sizes are represented by register classes with identical register sets: FR32, FR64, and VR128. These register classes have different spill slot sizes, so it is important to use the right one. The register class constraint on an instruction doesn't necessarily care about the size of the value its defining. The value type determines that. This fixes a problem where InstrEmitter was picking 32-bit register classes for 64-bit values on SPARC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199187 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'tools/lto')
0 files changed, 0 insertions, 0 deletions