Files
llvm/test/CodeGen/AMDGPU
Tim Northover 59282d3fd2 GlobalISel: move type information to MachineRegisterInfo.
We want each register to have a canonical type, which means the best place to
store this is in MachineRegisterInfo rather than on every MachineInstr that
happens to use or define that register.

Most changes following from this are pretty simple (you need an MRI anyway if
you're going to be doing any transformations, so just check the type there).
But legalization doesn't really want to check redundant operands (when, for
example, a G_ADD only ever has one type) so I've made use of MCInstrDesc's
operand type field to encode these constraints and limit legalization's work.

As an added bonus, more validation is possible, both in MachineVerifier and
MachineIRBuilder (coming soon).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281035 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-09 11:46:34 +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
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-07-15 21:27:13 +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
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-06-02 19:54:26 +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
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-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
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-07-22 17:01:21 +00:00
2016-07-22 17:01:21 +00:00
2016-07-22 17:01:21 +00:00
2016-07-22 17:01:21 +00:00
2016-06-02 19:54:26 +00:00
2015-06-13 03:28:10 +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
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
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
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-06-02 19:54:26 +00:00
2016-06-02 19:54:26 +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-05-05 20:07:37 +00:00
2016-06-15 00:11:01 +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-05-18 15:48:44 +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
2015-06-13 03:28:10 +00:00
2016-08-02 22:25:04 +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
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-09-03 06:57:55 +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
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
2015-06-13 03:28:10 +00:00
2016-05-05 20:07: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.