summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-objdump/llvm-objdump.h
diff options
context:
space:
mode:
authorQuentin Colombet <qcolombet@apple.com>2016-04-06 21:37:22 +0000
committerQuentin Colombet <qcolombet@apple.com>2016-04-06 21:37:22 +0000
commitc916204a81ea85b51c1469c4858b13a452fde4c0 (patch)
tree72cb07aafd43931fe3a99332fc6d838aeff35842 /llvm/tools/llvm-objdump/llvm-objdump.h
parentb92a34e458476ed7e2ae7af12ee785b1571a53c9 (diff)
downloadbcm5719-llvm-c916204a81ea85b51c1469c4858b13a452fde4c0.tar.gz
bcm5719-llvm-c916204a81ea85b51c1469c4858b13a452fde4c0.zip
[RegisterBankInfo] Add methods to get the possible mapping of an instruction on a register bank.
This will be used by the register bank select pass to assign register banks for generic virtual registers. This was originally committed as r265573 but broke at least one windows bot. The problem with the windows bot was that it was using a copy constructor for the InstructionMappings class and could not synthesize it. Actually, the fact that this class is not copy constructable is expected and the compiler should use the move assignment constructor. Marking the problematic assignment explicitly as using the move constructor has its own problems. Indeed, with recent clang we get a warning that we may prevent the elision of the copy by the compiler. A proper fix for both compilers would be to change the API of getPossibleInstrMapping to take a InstructionMappings as input/output parameter. This does not feel natural and since GISel is not used on windows yet, I chose to workaround the problem by not compiling the problematic code on windows. llvm-svn: 265604
Diffstat (limited to 'llvm/tools/llvm-objdump/llvm-objdump.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud