Files
llvm/test/CodeGen/AMDGPU
Sanjoy Das a942d77488 [Verifier] Add verification for TBAA metadata
Summary:
This change adds some verification in the IR verifier around struct path
TBAA metadata.

Other than some basic sanity checks (e.g. we get constant integers where
we expect constant integers), this checks:

 - That by the time an struct access tuple `(base-type, offset)` is
   "reduced" to a scalar base type, the offset is `0`.  For instance, in
   C++ you can't start from, say `("struct-a", 16)`, and end up with
   `("int", 4)` -- by the time the base type is `"int"`, the offset
   better be zero.  In particular, a variant of this invariant is needed
   for `llvm::getMostGenericTBAA` to be correct.

 - That there are no cycles in a struct path.

 - That struct type nodes have their offsets listed in an ascending
   order.

 - That when generating the struct access path, you eventually reach the
   access type listed in the tbaa tag node.

Reviewers: dexonsmith, chandlerc, reames, mehdi_amini, manmanren

Subscribers: mcrosier, llvm-commits

Differential Revision: https://reviews.llvm.org/D26438

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289402 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-11 20:07:15 +00:00
..
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2016-05-05 20:07:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-02-08 19:06:01 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-06-02 19:54:26 +00:00
2016-11-15 02:25:28 +00:00
2016-05-05 20:07:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-13 07:01:11 +00:00
2015-06-13 03:28:10 +00:00
2016-11-13 07:01:11 +00:00
2015-06-13 03:28:10 +00:00
2016-06-09 23:42:54 +00:00
2016-06-09 23:42:54 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-15 02:25:28 +00:00
2016-11-15 02:25:28 +00:00
2016-11-15 02:25:28 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-07-22 17:01:21 +00:00
2016-07-22 17:01:21 +00:00
2016-11-13 07:01:11 +00:00
2016-06-02 19:54:26 +00:00
2016-11-13 07:01:11 +00:00
2016-05-28 00:19:52 +00:00
2016-06-09 19:17:15 +00:00
2016-07-09 08:02:28 +00:00
2016-07-09 08:02:28 +00:00
2016-05-05 20:07:37 +00:00
2015-06-13 03:28:10 +00:00
2016-11-13 07:01:11 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-05-05 20:07:37 +00:00
2015-06-13 03:28:10 +00:00
2016-11-13 07:01:11 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-05-05 20:07:37 +00:00
2016-06-02 19:54:26 +00:00
2016-06-02 19:54:26 +00:00
2016-06-02 19:54:26 +00:00
2016-11-10 16:02:37 +00:00
2016-11-10 16:02:37 +00:00
2016-06-02 19:54:26 +00:00
2016-06-02 19:54:26 +00:00
2016-11-10 16:02:37 +00:00
2016-11-10 16:02:37 +00:00
2016-06-02 19:54:26 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-05-05 20:07:37 +00:00
2016-11-10 16:02:37 +00:00
2016-11-10 16:02:37 +00:00
2016-06-15 00:11:01 +00:00
2016-12-09 17:49:14 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-12-05 20:31:49 +00:00
2015-06-13 03:28:10 +00:00
2016-05-05 20:07:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-08-02 22:25:04 +00:00
2015-06-13 03:28:10 +00:00
2016-11-01 10:26:48 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-01 10:26:48 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-13 07:01:11 +00:00
2016-11-13 07:01:11 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2015-06-13 03:28:10 +00:00
2016-11-10 16:02:37 +00:00

+==============================================================================+
| How to organize the lit tests                                                |
+==============================================================================+

- If you write a test for matching a single DAG opcode or intrinsic, it should
  go in a file called {opcode_name,intrinsic_name}.ll (e.g. fadd.ll)

- If you write a test that matches several DAG opcodes and checks for a single
  ISA instruction, then that test should go in a file called {ISA_name}.ll (e.g.
  bfi_int.ll

- For all other tests, use your best judgement for organizing tests and naming
  the files.

+==============================================================================+
| Naming conventions                                                           |
+==============================================================================+

- Use dash '-' and not underscore '_' to separate words in file names, unless
  the file is named after a DAG opcode or ISA instruction that has an
  underscore '_' in its name.