summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-bcanalyzer/llvm-bcanalyzer.cpp
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2015-02-25 01:07:20 +0000
committerDavid Blaikie <dblaikie@gmail.com>2015-02-25 01:07:20 +0000
commit8503565eecfa630f8ee65266efc4a82e796ebc64 (patch)
treedb0a5b3bc473be4f8196af41c196a5761706fb8a /llvm/tools/llvm-bcanalyzer/llvm-bcanalyzer.cpp
parentc93a9a2cb4593839b2cd495c53d5b1c9cf456830 (diff)
downloadbcm5719-llvm-8503565eecfa630f8ee65266efc4a82e796ebc64.tar.gz
bcm5719-llvm-8503565eecfa630f8ee65266efc4a82e796ebc64.zip
[opaque pointer type] bitcode support for explicit type parameter to the load instruction
Summary: I've taken my best guess at this, but I've cargo culted in places & so explanations/corrections would be great. This seems to pass all the tests (check-all, covering clang and llvm) so I believe that pretty well exercises both the backwards compatibility and common (same version) compatibility given the number of checked in bitcode files we already have. Is that a reasonable approach to testing here? Would some more explicit tests be desired? 1) is this the right way to do back-compat in this case (looking at the number of entries in the bitcode record to disambiguate between the old schema and the new?) 2) I don't quite understand the logarithm logic to choose the encoding type of the type parameter in the abbreviation description, but I found another instruction doing the same thing & it seems to work. Is that the right approach? Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7655 llvm-svn: 230414
Diffstat (limited to 'llvm/tools/llvm-bcanalyzer/llvm-bcanalyzer.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud