Nicolai Haehnle 2ac1fa00c9 AMDGPU: Add amdgpu-ps-wqm-outputs function attributes
Summary:
The presence of this attribute indicates that VGPR outputs should be computed
in whole quad mode. This will be used by Mesa for prolog pixel shaders, so
that derivatives can be taken of shader inputs computed by the prolog, fixing
a bug.

The generated code could certainly be improved: if a prolog pixel shader is
used (which isn't common in modern OpenGL - they're used for gl_Color, polygon
stipples, and forcing per-sample interpolation), Mesa will use this attribute
unconditionally, because it has to be conservative. So WQM may be used in the
prolog when it isn't really needed, and furthermore a silly back-and-forth
switch is likely to happen at the boundary between prolog and main shader
parts.

Fixing this is a bit involved: we'd first have to add a mechanism by which
LLVM writes the WQM-related input requirements to the main shader part binary,
and then Mesa specializes the prolog part accordingly. At that point, we may
as well just compile a monolithic shader...

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95130

Reviewers: arsenm, tstellarAMD, mareko

Subscribers: arsenm, llvm-commits, kzhuravl

Differential Revision: http://reviews.llvm.org/D20839

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272063 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-07 21:37:17 +00:00
..
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-02-08 19:06:01 +00:00
2016-05-25 18:07:36 +00:00
2016-05-21 00:29:27 +00:00
2016-04-06 19:40:20 +00:00
2016-06-02 19:54:26 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-06-02 19:54:26 +00:00
2016-05-28 00:19:52 +00:00
2016-05-28 00:19:52 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-01-28 20:53:35 +00:00
2016-06-02 19:54:26 +00:00
2016-05-05 20:07:37 +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
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
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-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-18 15:48:44 +00:00
2016-04-06 19:40:20 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-05 20:07:37 +00:00
2016-05-21 00:29:40 +00:00
2016-05-05 20:07:37 +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.