diff options
| author | David Blaikie <dblaikie@gmail.com> | 2015-02-25 01:07:20 +0000 |
|---|---|---|
| committer | David Blaikie <dblaikie@gmail.com> | 2015-02-25 01:07:20 +0000 |
| commit | 8503565eecfa630f8ee65266efc4a82e796ebc64 (patch) | |
| tree | db0a5b3bc473be4f8196af41c196a5761706fb8a /llvm/tools/llvm-bcanalyzer/llvm-bcanalyzer.cpp | |
| parent | c93a9a2cb4593839b2cd495c53d5b1c9cf456830 (diff) | |
| download | bcm5719-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

