This checkin implements about half of the HLSL intrinsics for a subset of their
entire type support (but a useful subset). The uncommented lines in
TBuiltInParseablesHlsl::identifyBuiltIns shows which are connected.
When linking multiple compilation units per shader stage,
the code creates a new intermediate, but fails to set its
version and profile.
This change makes it so that the new intermediate inherits
the version and profile of the first compilation unit, so
that two ES SL compilation units can be combined.
Note: This required adding a new test mode to see the AST for vulkan tests.
This also required reworking some deeper parts of type creation, regarding
when storage qualification and constness is deduced bottom-up or dictated
top-down.
* Fixes a warning - static function being defined but not used.
* Just in case any more code is added to DetachThreadLinux, this will go
through the same path on both platforms.
This change causes ES shaders to precision qualifiers for build-in functions as defined in ESSL spec. It especially mattersfor functions that are defined as highp or taking a highp.
Fixes vulkanCTS dEQP-VK.glsl.builtin.function.integer.bitfieldreverse.*, where bitfieldReverse() retval was wrongly marked as RelaxedPrecision.
Note: floatBitsToInt/floatBitsToUInt precision is also broken, but in different way - so it is not addressed here.
1. Sink adding noContraction decoration to createBinaryOperation() and
createUnaryOperation().
2. Fix comments.
3. Remove the #define of my delimiter, use global constant char.
Reimplement the whole workflow to make that: precise'ness of struct
members won't spread to other non-precise members of the same struct
instance.
Approach:
1. Build the map from symbols to their defining nodes. And for each
object node (StructIndex, DirectIndex, Symbol nodes, etc), generates an
accesschain path. Different AST nodes that indicating a same object
should have the same accesschain path.
2. Along the building phase in step 1, collect the initial set of
'precise' (AST qualifier: 'noContraction') objects' accesschain paths.
3. Start with the initial set of 'precise' accesschain paths, use it as
a worklist, do as the following steps until the worklist is empty:
1) Pop an accesschain path from worklist.
2) Get the symbol part from the accesschain path.
3) Find the defining nodes of that symbol.
4) For each defining node, check whether it is defining a 'precise'
object, or its assignee has nested 'precise' object. Get the
incremental path from assignee to its nested 'precise' object (if
any).
5) Traverse the right side of the defining node, obtain the
accesschain paths of the corresponding involved 'precise' objects.
Update the worklist with those new objects' accesschain paths.
Label involved operations with 'noContraction'.
In each step, whenever we find the parent object of an nested object is
'precise' (has 'noContraction' qualifier), we let the nested object
inherit the 'precise'ness from its parent object.
