summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_cfg.h
Commit message (Collapse)AuthorAgeFilesLines
* glsl: Separate overlapping sentinel nodes in exec_list.Matt Turner2016-07-261-1/+1
| | | | | | | | | | | I do appreciate the cleverness, but unfortunately it prevents a lot more cleverness in the form of additional compiler optimizations brought on by -fstrict-aliasing. No difference in OglBatch7 (n=20). Co-authored-by: Davin McCall <davmac@davmac.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* i965: Simplify foreach_inst_in_block_safe() macro.Matt Turner2016-06-301-3/+2
| | | | | We know what the end looks like without examining .tail: it's NULL. It's always NULL.
* i965: Make bblock_t::next and friends return NULL at sentinels.Kenneth Graunke2016-04-041-0/+12
| | | | | | | | | The bblock_t::prev/prev_const/next/next_const API returns bblock_t pointers, rather than exec_nodes. So it's a bit surprising. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Do dead-code elimination in a single pass.Matt Turner2015-12-011-0/+3
| | | | | | | | | | | | The first pass marked dead instructions as opcode = NOP, and a second pass deleted those instructions so that the live ranges used in the first pass wouldn't change. But since we're walking the instructions in reverse order, we can just do everything in one pass. The only thing we have to do is walk the blocks in reverse as well. Reviewed-by: Francisco Jerez <currojerez@riseup.net>
* i965: dump scheduling cycle estimatesConnor Abbott2015-10-301-0/+4
| | | | | | | | | | | | | The heuristic we're using is rather lame, since it assumes everything is non-uniform and loops execute 10 times, but it should be enough for measuring improvements in the scheduler that don't result in a change in the number of instructions. v2: - Switch loops and cycle counts to be compatible with older shader-db. - Make loop heuristic 10x to match with spilling code. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
* i965: Remove block arg from foreach_inst_in_block_*_starting_fromNeil Roberts2015-10-211-2/+2
| | | | | | | | | Since 49374fab5d793 these macros no longer actually use the block argument. I think this is worth doing to make the macros easier to use because they already have really long names and a confusing set of arguments. Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Rename backend_visitor to backend_shaderJason Ekstrand2015-05-281-2/+2
| | | | | | | | The backend_shader class really is a representation of a shader. The fact that it inherits from ir_visitor is somewhat immaterial. Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/cfg: Add function to generate a dot file of the dominator tree.Matt Turner2015-02-171-0/+1
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/cfg: Add function to generate a dot file of the CFG.Matt Turner2015-02-171-0/+1
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/cfg: Calculate the immediate dominators.Matt Turner2015-02-171-1/+6
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/cfg: Add a foreach_block_reverse macro.Matt Turner2015-01-231-0/+3
| | | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
* i965/cfg: Add a foreach_inst_in_block_reverse_safe macro.Matt Turner2015-01-231-0/+3
| | | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
* i965/cfg: Remove if_block/else_block.Matt Turner2014-11-111-8/+0
| | | | | | | | I used these in the SEL peephole, but they require extra tracking and fix ups. The SEL peephole can pretty easily find the blocks it needs without these. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
* i965/cfg: Add functions to get first and last non-CF instructions.Matt Turner2014-11-061-0/+74
| | | | Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
* i965: Add and use functions to get next/prev blocks.Matt Turner2014-09-241-0/+53
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Make instruction lists local to the bblocks.Matt Turner2014-09-241-15/+62
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add note about double-loop macros and break behavior.Matt Turner2014-09-241-0/+6
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add macros to iterate through a block given a starting point.Matt Turner2014-09-241-0/+10
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Mark cfg dumping functions const.Kenneth Graunke2014-09-051-2/+2
| | | | | | | | | | The dump() methods don't alter the CFG or basic blocks, so we should mark them as const. This lets you call them even if you have a const cfg_t - which is the case in certain portions of the code (such as live interval handling). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965/cfg: Add functions to combine basic blocks.Matt Turner2014-08-221-0/+2
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Point to bblock_t containing associated control flowMatt Turner2014-08-221-6/+4
| | | | | | | | | | | | | | | | | | | | | ... rather than pointing directly to the associated instruction. This will let us set the block containing the IF statement's else-pointer to NULL, when we delete a useless ELSE instruction, as in the case (+f0) if(8) ... else(8) endif(8) Also, remove the pointer to the ENDIF, since it's unused, and it was also potentially wrong, in the case of a basic block containing both an ENDIF and an IF instruction: endif(8) cmp.ne.f0(8) ... (+f0) if(8) Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add a function to remove a block from the cfg.Matt Turner2014-08-221-1/+4
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add functions to test if a block is a successor/predecessor.Matt Turner2014-08-221-0/+2
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add a foreach_block_and_inst_safe macro.Matt Turner2014-08-181-0/+4
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add a foreach_inst_in_block_safe macro.Matt Turner2014-08-181-0/+8
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add a foreach_block_safe macro.Matt Turner2014-08-181-0/+3
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Add and use foreach_block macro.Matt Turner2014-08-181-1/+4
| | | | | Use this as an opportunity to rename 'block_num' to 'num'. block->num is clear, and block->block_num has always been redundant.
* i965/cfg: Embed link in bblock_t for main block list.Matt Turner2014-08-181-0/+2
| | | | | | | | The next patch adds a foreach_block (block, cfg) macro, which works better if it provides a direct bblock_t pointer, rather than a bblock_link pointer that you have to use to find the actual block. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Add a foreach_block_and_inst macro.Matt Turner2014-07-211-0/+4
| | | | | | Will let us abstract how the instructions are stored. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965/cfg: Make cfg_t usable from C.Matt Turner2014-07-051-6/+4
| | | | Acked-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Add and use foreach_inst_in_block macros.Matt Turner2014-07-011-0/+10
| | | | Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* i965/cfg: Embed exec_node in bblock_link.Matt Turner2014-05-151-1/+2
| | | | | | | In order to remove bblock_link's inheritance of exec_node. Also makes linked list walk code much nicer. Acked-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Make brw_cfg.h closer to C-includable.Matt Turner2014-05-151-13/+23
| | | | | | Only bblock_link's inheritance left. Acked-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Protect brw_cfg.h from multiple inclusion.Matt Turner2014-05-151-0/+6
| | | | Acked-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Remove ip & cur from brw_cfg.Matt Turner2013-12-041-9/+1
| | | | Reviewed-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Clean up cfg_t constructors.Matt Turner2013-12-041-4/+1
| | | | | | | parent_mem_ctx was unused since db47074a, so remove the two wrappers around create() and make create() the constructor. Reviewed-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Throw out confusing make_list method.Matt Turner2013-12-041-2/+0
| | | | | | | make_list is just a one-line wrapper and was confusingly called by NULL objects. E.g., cur_if == NULL; cur_if->make_list(mem_ctx). Reviewed-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Include only needed headers.Matt Turner2013-12-041-1/+3
| | | | Reviewed-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Keep pointers to IF/ELSE/ENDIF instructions in the cfg.Matt Turner2013-12-041-0/+10
| | | | | | | Useful for finding the associated control flow instructions, given a block ending in one. Reviewed-by: Eric Anholt <eric@anholt.net>
* i965/cfg: Add code to dump blocks and cfg.Matt Turner2013-12-041-0/+3
| | | | Reviewed-by: Eric Anholt <eric@anholt.net>
* i965: Initialize all member variables of cfg_t on construction.Francisco Jerez2013-10-011-1/+1
| | | | | | | | | | | | | The cfg_t object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Initialize all member variables of bblock_t on construction.Francisco Jerez2013-10-011-1/+1
| | | | | | | | | | | | | | | The bblock_t object relies on the memory allocator zeroing out its contents before it's initialized, which is quite an unusual practice in the C++ world because it ties objects to some specific allocation scheme, and gives unpredictable results when an object is created with a different allocator -- Stack allocation, array allocation, or aggregation inside a different object are some of the useful possibilities that come to my mind. Initialize all fields from the constructor and stop using the zeroing allocator. v2: Use zero initialization for numeric types instead of default construction. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965, mesa: Use the new DECLARE_R[Z]ALLOC_CXX_OPERATORS macros.Kenneth Graunke2013-09-211-18/+2
| | | | | | | | | | | | | | | | These classes declared a placement new operator, but didn't declare a delete operator. Switching to the macro gives them a delete operator, which probably is a good idea anyway. This also eliminates a lot of boilerplate. v2: Properly use RZALLOC in Mesa IR/TGSI translators. Caught by Eric and Chad. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* i965: Make it possible to create a cfg_t without a backend_visitor.Kenneth Graunke2012-11-261-0/+4
| | | | | | | | | | All we really need is a memory context and the instruction list; passing a backend_visitor is just convenient at times. This will be necessary two patches from now. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Make the cfg reusable from the VS.Eric Anholt2012-10-171-3/+3
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Rename fs_cfg types to not mention fs.Eric Anholt2012-10-171-14/+14
| | | | | | | | fs_bblock_link -> bblock_link fs_bblock -> bblock_t (to avoid conflicting with all the fs_bblock *bblock) fs_cfg -> cfg_t (to avoid conflicting with all the fs_cfg *cfg) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Move brw_fs_cfg.* to brw_cfg.*.Eric Anholt2012-10-171-0/+101
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>