maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Assembler/invalid-opaque-ptr-double-a...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

5 lines
165 B
LLVM
Raw Normal View History

[OpaquePtr] Forbid mixing typed and opaque pointers Currently, opaque pointers are supported in two forms: The -force-opaque-pointers mode, where all pointers are opaque and typed pointers do not exist. And as a simple ptr type that can coexist with typed pointers. This patch removes support for the mixed mode. You either get typed pointers, or you get opaque pointers, but not both. In the (current) default mode, using ptr is forbidden. In -opaque-pointers mode, all pointers are opaque. The motivation here is that the mixed mode introduces additional issues that don't exist in fully opaque mode. D105155 is an example of a design problem. Looking at D109259, it would probably need additional work to support mixed mode (e.g. to generate GEPs for typed base but opaque result). Mixed mode will also end up inserting many casts between i8* and ptr, which would require significant additional work to consistently avoid. I don't think the mixed mode is particularly valuable, as it doesn't align with our end goal. The only thing I've found it to be moderately useful for is adding some opaque pointer tests in between typed pointer tests, but I think we can live without that. Differential Revision: https://reviews.llvm.org/D109290
2021-09-04 18:18:52 +08:00
; RUN: not llvm-as < %s -opaque-pointers -disable-output 2>&1 | FileCheck %s
OpaquePtr: Support i32** with --force-opaque-pointers 4506f614cb6983a16d117cf77a968608e66d7a5c fixed parsing of textual IR to reject `ptr*`, but broke the auto-conversion of `i32**` to `ptr` with `--force-opaque-pointers`. Get that working again by refactoring LLParser::parseType to only send `ptr`-spelled pointers into the type suffix logic when it's the return of a function type. This also rejects `ptr addrspace(3) addrspace(2)`, which 1e6303e60ca5af4fbe7ca728572fd65666a98271 invadvertently started accepting. Just the default top-level error message for the double-addrspace since I had trouble thinking of something nice; probably it's fine as is (it doesn't look valid the way that `ptr*` does). Differential Revision: https://reviews.llvm.org/D105146
2021-06-30 03:49:57 +08:00
; CHECK: expected top-level entity
@g1 = external global ptr addrspace(3) addrspace(4)