aboutsummaryrefslogtreecommitdiffstats
path: root/src/compiler/nir/nir_algebraic.py
Commit message (Collapse)AuthorAgeFilesLines
* nir/algebraic: Add the ability to mark a replacement as exactIan Romanick2019-11-041-2/+6
| | | | | Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Connor Abbott <[email protected]>
* nir: correct use of identity check in pythonDylan Baker2019-11-041-2/+2
| | | | | | | | | | Python has the identity operator `is`, and the equality operator `==`. Using `is` with strings sometimes works in CPython due to optimizations (they have some kind of cache), but it may not always work. Fixes: 96c4b135e34d0804e41bfbc28fc1b5050c49d71e ("nir/algebraic: Don't put quotes around floating point literals") Reviewed-by: Matt Turner <[email protected]>
* nir: Factor out most of the algebraic passes C code to .c/.h.Eric Anholt2019-10-041-146/+22
| | | | | | | | | | | Working on the algebraic implementation, I was being driven nuts by my editor not highlighting and handling indentation for the C code. It turns out that it's basically not pass-specific code, and we can move it over to the relevant .c file. Replaces 30KB of code with 34KB of data on my i965 build. No perf diff on shader-db (n=3) Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Connor Abbott <[email protected]>
* nir: Keep the range analysis HT around intra-pass until we make a change.Eric Anholt2019-10-041-2/+7
| | | | | | | | | This lets us memoize range analysis work across instructions. Reduces runtime of shader-db on Intel by -30.0288% +/- 2.1693% (n=3). Fixes: 405de7ccb6cb ("nir/range-analysis: Rudimentary value range analysis pass") Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: refactor inexact opcode restrictionsSamuel Iglesias Gonsálvez2019-09-191-3/+5
| | | | | | | | | | Refactor the code to avoid calling a lot of time to auxiliary functions when it is not really needed. Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* nir/algebraic: disable inexact optimizations depending on float controls ↵Samuel Iglesias Gonsálvez2019-09-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | execution mode If FLOAT_CONTROLS_SIGNED_ZERO_INF_NAN_PRESERVE or FLOAT_CONTROLS_DENORM_FLUSH_TO_ZERO are enabled, do not apply the inexact optimizations so the VK_KHR_shader_float_controls execution mode is respected. v2: - Do not apply inexact optimizations if SHADER_DENORM_FLUSH_TO_ZERO is enabled (Andres). v3: - Updated to renamed shader info member (Andres). v4: - Directly access execution mode instead of dragging it by parameter (Caio). Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Signed-off-by: Andres Gomez <[email protected]> Reviewed-by: Connor Abbott <[email protected]> [v1]
* nir/algebraic: allow swizzle in nir_algebraic replace expressionJonathan Marek2019-07-241-1/+10
| | | | | | | | This is to allow optimizations in nir_opt_algebraic not otherwise possible Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Acked-by: Matt Turner <[email protected]>
* nir/algebraic: Print out the list of transforms in the C fileJason Ekstrand2019-07-171-0/+7
| | | | | | | | This helps greatly when debugging algebraic transform generators because you can now actually see the output and verify that your transforms are getting generated. Acked-by: Matt Turner <[email protected]>
* nir/serach: Increase maximum commutative expressions from 4 to 8Ian Romanick2019-06-281-1/+1
| | | | | | | | No shader-db change on any Intel platform. No shader-db run-time difference on a certain 36-core / 72-thread system at 95% confidence (n=20). Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Don't mark expression with duplicate sources as commutativeIan Romanick2019-06-281-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no reason to mark the fmul in the expression ('fmul', ('fadd', a, b), ('fadd', a, b)) as commutative. If a source of an instruction doesn't match one of the ('fadd', a, b) patterns, it won't match the other either. This change is enough to make this pattern work: ('~fadd@32', ('fmul', ('fadd', 1.0, ('fneg', a)), ('fadd', 1.0, ('fneg', a))), ('fmul', ('flrp', a, 1.0, a), b)) This pattern has 5 commutative expressions (versus a limit of 4), but the first fmul does not need to be commutative. No shader-db change on any Intel platform. No shader-db run-time difference on a certain 36-core / 72-thread system at 95% confidence (n=20). There are more subpatterns that could be marked as non-commutative, but detecting these is more challenging. For example, this fadd: ('fadd', ('fmul', a, b), ('fmul', a, c)) The first fadd: ('fmul', ('fadd', a, b), ('fadd', a, b)) And this fadd: ('flt', ('fadd', a, b), 0.0) This last case may be easier to detect. If all sources are variables and they are the only instances of those variables, then the pattern can be marked as non-commutative. It's probably not worth the effort now, but if we end up with some patterns that bump up on the limit again, it may be worth revisiting. v2: Update the comment about the explicit "len(self.sources)" check to be more clear about why it is necessary. Requested by Connor. Many Python fixes style / idom fixes suggested by Dylan. Add missing (!!!) opcode check in Expression::__eq__ method. This bug is the reason the expected number of commutative expressions in the bitfield_reverse pattern changed from 61 to 45 in the first version of this patch. v3: Use all() in Expression::__eq__ method. Suggested by Connor. Revert away from using __eq__ overloads. The "equality" implementation of Constant and Variable needed for commutativity pruning is weaker than the one needed for propagating and validating bit sizes. Using actual equality caused the pruning to fail for my ('fmul', ('fadd', 1, a), ('fadd', 1, a)) case. I changed the name to "equivalent" rather than the previous "same_as" to further differentiate it from __eq__. Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* nir/algebraic: Fail build when too many commutative expressions are usedIan Romanick2019-06-281-0/+43
| | | | | | | | | | | | | | Search patterns that are expected to have too many (e.g., the giant bitfield_reverse pattern) can be added to a white list. This would have saved me a few hours debugging. :( v2: Implement the expected-failure annotation as a property of the search-replace pattern instead of as a property of the whole list of patterns. Suggested by Connor. Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* nir/algebraic: Fix whitespace errorIan Romanick2019-06-281-1/+0
| | | | | | | Trivial Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* nir: Add support for 2src_commutative ops that have 3 sourcesIan Romanick2019-05-141-2/+2
| | | | | | | | | | v2: Instead of handling 3 sources as a special case, generalize with loops to N sources. Suggested by Jason. v3: Further generalize by only checking that number of sources is >= 2. Suggested by Jason. Reviewed-by: Jason Ekstrand <[email protected]>
* nir: Rename commutative to 2src_commutativeIan Romanick2019-05-141-2/+2
| | | | | | | | | | | | | | | | | | | | The meaning of the new name is that the first two sources are commutative. Since this is only currently applied to two-source operations, there is no change. A future change will mark ffma as 2src_commutative. It is also possible that future work will add 3src_commutative for opcodes like fmin3. v2: s/commutative_2src/2src_commutative/g. I had originally considered this, but I discarded it because I did't want to deal with identifiers that (should) start with 2. Jason suggested it in review, so we decided that _2src_commutative would be used in nir_opcodes.py. Also add some comments documenting what 2src_commutative means. Also suggested by Jason. Reviewed-by: Jason Ekstrand <[email protected]>
* nir/algebraic: Don't emit empty initializers for MSVCConnor Abbott2019-05-041-0/+4
| | | | | | | | | Just don't emit the transform array at all if there are no transforms v2: - Don't use len(array) > 0 (Dylan) - Keep using ARRAY_SIZE to make the generated C code easier to read (Jason).
* nir/search: Add automaton-based pre-searchingConnor Abbott2019-05-021-19/+377
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nir_opt_algebraic is currently one of the most expensive NIR passes, because of the many different patterns we've added over the years. Even though patterns are already sorted by opcode, there are still way too many patterns for common opcodes like bcsel and fadd, which means that many patterns are tried but only a few actually match. One way to fix this is to add a pre-pass over the code that scans it using an automaton constructed beforehand, similar to the automatons produced by lex and yacc for parsing source code. This automaton has to walk the SSA graph and recognize possible pattern matches. It turns out that the theory to do this is quite mature already, having been developed for instruction selection as well as other non-compiler things. I followed the presentation in the dissertation cited in the code, "Tree algorithms: Two Taxonomies and a Toolkit," trying to keep the naming similar. To create the automaton, we have to perform something like the classical NFA to DFA subset construction used by lex, but it turns out that actually computing the transition table for all possible states would be way too expensive, with the dissertation reporting times of almost half an hour for an example of size similar to nir_opt_algebraic. Instead, we adopt one of the "filter" approaches explained in the dissertation, which trade much faster table generation and table size for a few more table lookups per instruction at runtime. I chose the filter which resulted the fastest table generation time, with medium table size. Right now, the table generation takes around .5 seconds, despite being implemented in pure Python, which I think is good enough. Based on the numbers in the dissertation, the other choice might make table compilation time 25x slower to get 4x smaller table size, but I don't think that's worth it. As of now, we get the following binary size before and after this patch: text data bss dec hex filename 11979455 464720 730864 13175039 c908ff before i965_dri.so text data bss dec hex filename 12037835 616244 791792 13445871 cd2aef after i965_dri.so There are a number of places where I've simplified the automaton by getting rid of details in the LHS patterns rather than complicate things to deal with them. For example, right now the automaton doesn't distinguish between constants with different values. This means that it isn't as precise as it could be, but the decrease in compile time is still worth it -- these are the compilation time numbers for a shader-db run with my (admittedly old) database on Intel skylake: Difference at 95.0% confidence -42.3485 +/- 1.375 -7.20383% +/- 0.229926% (Student's t, pooled s = 1.69843) We can always experiment with making it more precise later. Reviewed-by: Jason Ekstrand <[email protected]>
* nir/algebraic: Use a cache to avoid re-emitting structsJason Ekstrand2019-04-161-17/+36
| | | | | | | | | | | | | | | | | | | This takes the stupid simplest and most reliable approach to reducing redundancy that I could come up with: Just use the struct declaration as the cach key. This cuts the size of the generated C file to about half and takes about 50 KiB off the .data section. size before (release build): text data bss dec hex filename 5363833 336880 13584 5714297 573179 _install/lib64/libvulkan_intel.so size after (release build): text data bss dec hex filename 5229017 285264 13584 5527865 545939 _install/lib64/libvulkan_intel.so Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Move the template closer to the render functionJason Ekstrand2019-04-161-19/+19
| | | | Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Lower CS derivatives to zero when no group definedCaio Marcelo de Oliveira Filho2019-04-081-0/+2
| | | | | | | | | | | In compute shaders if no derivative group is defined, the derivatives will always be zero. Specified in NV_compute_shader_derivatives. To make the check more convenient, add a "info" local variable to the generated code so we can refer to it in the Python rules. (Jason) Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* nir/search: Search for all combinations of commutative opsJason Ekstrand2019-04-081-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following search expression and NIR sequence: ('iadd', ('imul', a, b), b) ssa_2 = imul ssa_0, ssa_1 ssa_3 = iadd ssa_2, ssa_0 The current algorithm is greedy and, the moment the imul finds a match, it commits those variable names and returns success. In the above example, it maps a -> ssa_0 and b -> ssa_1. When we then try to match the iadd, it sees that ssa_0 is not b and fails to match. The iadd match will attempt to flip itself and try again (which won't work) but it cannot ask the imul to try a flipped match. This commit instead counts the number of commutative ops in each expression and assigns an index to each. It then does a loop and loops over the full combinatorial matrix of commutative operations. In order to keep things sane, we limit it to at most 4 commutative operations (16 combinations). There is only one optimization in opt_algebraic that goes over this limit and it's the bitfieldReverse detection for some UE4 demo. Shader-db results on Kaby Lake: total instructions in shared programs: 15310125 -> 15302469 (-0.05%) instructions in affected programs: 1797123 -> 1789467 (-0.43%) helped: 6751 HURT: 2264 total cycles in shared programs: 357346617 -> 357202526 (-0.04%) cycles in affected programs: 15931005 -> 15786914 (-0.90%) helped: 6024 HURT: 3436 total loops in shared programs: 4360 -> 4360 (0.00%) loops in affected programs: 0 -> 0 helped: 0 HURT: 0 total spills in shared programs: 23675 -> 23666 (-0.04%) spills in affected programs: 235 -> 226 (-3.83%) helped: 5 HURT: 1 total fills in shared programs: 32040 -> 32032 (-0.02%) fills in affected programs: 190 -> 182 (-4.21%) helped: 6 HURT: 2 LOST: 18 GAINED: 5 Reviewed-by: Thomas Helland <[email protected]>
* nir: Unset metadata debug bit if no progress madeMatt Turner2019-01-091-1/+6
| | | | | | | | | | | | | | | | | | | | | NIR metadata validation verifies that the debug bit was unset (by a call to nir_metadata_preserve) if a NIR optimization pass made progress on the shader. With the expectation that the NIR shader consists of only a single main function, it has been safe to call nir_metadata_preserve() iff progress was made. However, most optimization passes calculate progress per-function and then return the union of those calculations. In the case that an optimization pass makes progress only on a subset of the functions in the shader metadata validation will detect the debug bit is still set on any unchanged functions resulting in a failed assertion. This patch offers a quick solution (short of a larger scale refactoring which I do not wish to undertake as part of this series) that simply unsets the debug bit on unchanged functions. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* nir/algebraic: Don't put quotes around floating point literalsIan Romanick2018-12-181-0/+8
| | | | | | | | | | | | | | | | | | The quotation marks around 1.0 cause it to be treated as a string instead of a floating point value. The generator then treats it as an arbitrary variable replacement, so any iand involving a ('ineg', ('b2i', a)) matches. v2: Remove misleading comment about sized literals (suggested by Timothy). Add assertion that the name of a varible is entierly alphabetic (suggested by Jason). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Tested-by: Timothy Arceri <[email protected]> [v1] Reviewed-by: Timothy Arceri <[email protected]> [v1] Fixes: 6bcd2af0863 ("nir/algebraic: Add some optimizations for D3D-style Booleans") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109075
* nir/algebraic: Optimize 1-bit BooleansJason Ekstrand2018-12-161-34/+6
| | | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> Tested-by: Bas Nieuwenhuizen <[email protected]>
* nir: Rename Boolean-related opcodes to include 32 in the nameJason Ekstrand2018-12-161-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a squash of a bunch of individual changes: nir/builder: Generate 32-bit bool opcodes transparently nir/algebraic: Remap Boolean opcodes to the 32-bit variant Use 32-bit opcodes in the NIR producers and optimizations Generated with a little hand-editing and the following sed commands: sed -i 's/nir_op_ball_fequal/nir_op_b32all_fequal/g' **/*.c sed -i 's/nir_op_bany_fnequal/nir_op_b32any_fnequal/g' **/*.c sed -i 's/nir_op_ball_iequal/nir_op_b32all_iequal/g' **/*.c sed -i 's/nir_op_bany_inequal/nir_op_b32any_inequal/g' **/*.c sed -i 's/nir_op_\([fiu]lt\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fiu]ge\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fiu]ne\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fiu]eq\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fi]\)ne32g/nir_op_\1neg/g' **/*.c sed -i 's/nir_op_bcsel/nir_op_b32csel/g' **/*.c Use 32-bit opcodes in the NIR back-ends Generated with a little hand-editing and the following sed commands: sed -i 's/nir_op_ball_fequal/nir_op_b32all_fequal/g' **/*.c sed -i 's/nir_op_bany_fnequal/nir_op_b32any_fnequal/g' **/*.c sed -i 's/nir_op_ball_iequal/nir_op_b32all_iequal/g' **/*.c sed -i 's/nir_op_bany_inequal/nir_op_b32any_inequal/g' **/*.c sed -i 's/nir_op_\([fiu]lt\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fiu]ge\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fiu]ne\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fiu]eq\)/nir_op_\132/g' **/*.c sed -i 's/nir_op_\([fi]\)ne32g/nir_op_\1neg/g' **/*.c sed -i 's/nir_op_bcsel/nir_op_b32csel/g' **/*.c Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> Tested-by: Bas Nieuwenhuizen <[email protected]>
* nir: Make boolean conversions sized just like the othersJason Ekstrand2018-12-051-0/+4
| | | | | | | | | Instead of a single i2b and b2i, we now have i2b32 and b2iN where N is one if 8, 16, 32, or 64. This leads to having a few more opcodes but now everything is consistent and booleans aren't a weird special case anymore. Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Add support for unsized conversion opcodesJason Ekstrand2018-12-051-3/+44
| | | | | | | | | | | | All conversion opcodes require a destination size but this makes constructing certain algebraic expressions rather cumbersome. This commit adds support to nir_search and nir_algebraic for writing conversion opcodes without a size. These meta-opcodes match any conversion of that type regardless of destination size and the size gets inferred from the sizes of the things being matched or from other opcodes in the expression. Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Refactor codegen a bitJason Ekstrand2018-12-051-10/+11
| | | | | | | Instead of using an OrderedDict, just have a (necessarily sorted) array of transforms and a set of opcodes. Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Clean up some __str__ cruftJason Ekstrand2018-12-051-4/+0
| | | | | | | Both of these things are already handled in the Value base class so we don't need to handle them explicitly in Constant. Reviewed-by: Connor Abbott <[email protected]>
* nir/algebraic: Rewrite bit-size inferenceConnor Abbott2018-12-051-236/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there were two copies of the algorithm: one in C, that we would use to figure out what bit-size to give the replacement expression, and one in Python, that emulated the C one and tried to prove that the C algorithm would never fail to correctly assign bit-sizes. That seemed pretty fragile, and likely to fall over if we make any changes. Furthermore, the C code was really just recomputing more-or-less the same thing as the Python code every time. Instead, we can just store the results of the Python algorithm in the C datastructure, and consult it to compute the bitsize of each value, moving the "brains" entirely into Python. Since the Python algorithm no longer has to match C, it's also a lot easier to change it to something more closely approximating an actual type-inference algorithm. The algorithm used is based on Hindley-Milner, although deliberately weakened a little. It's a few more lines than the old one, judging by the diffstat, but I think it's easier to verify that it's correct while being as general as possible. We could split this up into two changes, first making the C code use the results of the Python code and then rewriting the Python algorithm, but since the old algorithm never tracked which variable each equivalence class, it would mean we'd have to add some non-trivial code which would then get thrown away. I think it's better to see the final state all at once, although I could also try splitting it up. v2: - Replace instances of "== None" and "!= None" with "is None" and "is not None". - Rename first_src to first_unsized_src - Only merge the destination with the first unsized source, since the sources have already been merged. - Add a comment explaining what nir_search_value::bit_size now means. v3: - Fix one last instance to use "is not" instead of != - Don't try to be so clever when choosing which error message to print based on whether we're in the search or replace expression. - Fix trailing whitespace. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* nir/search: Use the nir_imm_* helpers from nir_builderJason Ekstrand2018-10-261-6/+8
| | | | | | | | This requires that we rework the interface a bit to use nir_builder but that's a nice little modernization anyway. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* nir/algebraic: Fix a typo in the bit size validation codeJason Ekstrand2018-10-231-2/+2
| | | | | | | | The conon_bit_class and canon_var_class variables got switched. Fixes: 932c650e0b "nir/algebraic: Loosen a restriction on variables" Reported-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* nir/algebraic: Provide descriptive asserts for bit size checksJason Ekstrand2018-10-221-9/+42
| | | | | | | This will hopefully make debugging opt_algebraic bit-size compile failures easier. Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* nir/algebraic: Loosen a restriction on variablesJason Ekstrand2018-10-221-2/+6
| | | | | | | | | Previously, we would fail if a variable had an assigned but unknown bit size X and we tried to assign it an actual bit size. However, this is ok because, at the time we do the search, the variable does have an actual bit size and it will match X because of the NIR rules. Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* nir/algebraic: A bit of validation refactoring'Jason Ekstrand2018-10-221-15/+15
| | | | | | | We rename some local variables in validate() to be more readable and plumb the var through to get/set_var_bit_class instead of the var index. Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* nir/algebraic: Make internal classes str-ableJason Ekstrand2018-10-221-4/+12
| | | | Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* nir/algebraic: Use bool internally instead of bool32Jason Ekstrand2018-10-221-2/+2
| | | | Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* python: Better check for integer typesMathieu Bridon2018-08-091-3/+5
| | | | | | | | | | | | Python 3 lost the long type: now everything is an int, with the right size. This commit makes the script compatible with Python 2 (where we check for both int and long) and Python 3 (where we only check for int). Signed-off-by: Mathieu Bridon <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* python: Do not mix bytes and unicode stringsMathieu Bridon2018-08-091-1/+10
| | | | | | | | | | | | Mixing the two is a long-standing recipe for errors in Python 2, so much so that Python 3 now completely separates them. This commit stops treating both as if they were the same, and in the process makes the script compatible with both Python 2 and 3. Signed-off-by: Mathieu Bridon <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* python: Explicitly add the 'L' suffix on Python 3Mathieu Bridon2018-08-011-1/+10
| | | | | | | | | | | | | | | Python 2 had two integer types: int and long. Python 3 dropped the latter, as it made the int type automatically support bigger numbers. As a result, Python 3 lost the 'L' suffix on integer litterals. This probably doesn't make much difference when compiling the generated C code, but adding it explicitly means that both Python 2 and 3 generate the exact same C code anyway, which makes it easier to compare and check for discrepencies when moving to Python 3. Signed-off-by: Mathieu Bridon <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* python: Don't abuse hex()Mathieu Bridon2018-08-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hex() builtin returns a string containing the hexa-decimal representation of an integer. When the argument is not an integer, then the function calls that object's __hex__() method, if one is defined. That method is supposed to return a string. While that's not explicitly documented, that string is supposed to be a valid hexa-decimal representation for a number. Python 2 doesn't enforce this though, which is why we got away with returning things like 'NIR_TRUE' which are not numbers. In Python 3, the hex() builtin instead calls an object's __index__() method, which itself must return an integer. That integer is then automatically converted to a string with its hexa-decimal representation by the rest of the hex() function. As a result, we really can't make this compatible with Python 3 as it is. The solution is to stop using the hex() builtin, and instead use a hex() object method, which can return whatever we want, in Python 2 and 3. Signed-off-by: Mathieu Bridon <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* python: Better use iteratorsMathieu Bridon2018-07-241-2/+2
| | | | | | | | | | | | | | | | | In Python 2, iterators had a .next() method. In Python 3, instead they have a .__next__() method, which is automatically called by the next() builtin. In addition, it is better to use the iter() builtin to create an iterator, rather than calling its __iter__() method. These were also introduced in Python 2.6, so using it makes the script compatible with Python 2 and 3. Signed-off-by: Mathieu Bridon <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* python: Better iterate over dictionariesMathieu Bridon2018-07-241-1/+1
| | | | | | | | | | | | | | | | In Python 2, dictionaries have 2 sets of methods to iterate over their keys and values: keys()/values()/items() and iterkeys()/itervalues()/iteritems(). The former return lists while the latter return iterators. Python 3 dropped the method which return lists, and renamed the methods returning iterators to keys()/values()/items(). Using those names makes the scripts compatible with both Python 2 and 3. Signed-off-by: Mathieu Bridon <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* python: Stabilize some script outputsMathieu Bridon2018-07-051-1/+2
| | | | | | | | | | | | In Python, dictionaries and sets are unordered, and as a result their is no guarantee that running this script twice will produce the same output. Using ordered dicts and explicitly sorting items makes the build more reproducible, and will make it possible to verify that we're not breaking anything when we move the build scripts to Python 3. Reviewed-by: Eric Engestrom <[email protected]>
* nir: remove shebang from python scriptsEmil Velikov2017-03-101-1/+0
| | | | | | | Analogous to earlier commit(s). Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* nir/algebraic: Only include nir_search_helpers onceJason Ekstrand2017-01-191-1/+1
| | | | | | | We were including it once per value, so probably around 10k times. Let's not cause the compiler any more work than we have to. Reviewed-by: Iago Toral Quiroga <[email protected]>
* nir/algebraic: add support for conditional helper functions to expressionsTimothy Arceri2017-01-121-1/+4
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* nir/algebraic: support for power-of-two optimizationsRob Clark2016-06-031-2/+6
| | | | | | | | | | | | Some optimizations, like converting integer multiply/divide into left/ right shifts, have additional constraints on the search expression. Like requiring that a variable is a constant power of two. Support these cases by allowing a fxn name to be appended to the search var expression (ie. "a#32(is_power_of_two)"). Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* nir: Switch the arguments to nir_foreach_functionJason Ekstrand2016-04-281-1/+1
| | | | | | | | | This matches the "foreach x in container" pattern found in many other programming languages. Generated by the following regular expression: s/nir_foreach_function(\([^,]*\),\s*\([^,]*\))/nir_foreach_function(\2, \1)/ Reviewed-by: Ian Romanick <[email protected]>
* nir: Switch the arguments to nir_foreach_instrJason Ekstrand2016-04-281-1/+1
| | | | | | | | | | | This matches the "foreach x in container" pattern found in many other programming languages. Generated by the following regular expression: s/nir_foreach_instr(\([^,]*\),\s*\([^,]*\))/nir_foreach_instr(\2, \1)/ and similar expressions for nir_foreach_instr_safe etc. Reviewed-by: Ian Romanick <[email protected]>
* nir/algebraic: fixup for new foreach_block()Connor Abbott2016-04-281-20/+14
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 03:37:04 +0000