2014-08-22 10:54:43 -07:00
|
|
|
/*
|
|
|
|
|
* Copyright © 2014 Intel Corporation
|
|
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
|
* Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "brw_fs.h"
|
|
|
|
|
#include "brw_cfg.h"
|
2015-11-22 18:27:42 -08:00
|
|
|
#include "brw_eu.h"
|
2014-08-22 10:54:43 -07:00
|
|
|
|
|
|
|
|
/** @file brw_fs_cmod_propagation.cpp
|
|
|
|
|
*
|
|
|
|
|
* Implements a pass that propagates the conditional modifier from a CMP x 0.0
|
|
|
|
|
* instruction into the instruction that generated x. For instance, in this
|
|
|
|
|
* sequence
|
|
|
|
|
*
|
|
|
|
|
* add(8) g70<1>F g69<8,8,1>F 4096F
|
|
|
|
|
* cmp.ge.f0(8) null g70<8,8,1>F 0F
|
|
|
|
|
*
|
|
|
|
|
* we can do the comparison as part of the ADD instruction directly:
|
|
|
|
|
*
|
|
|
|
|
* add.ge.f0(8) g70<1>F g69<8,8,1>F 4096F
|
2015-01-03 12:18:15 -08:00
|
|
|
*
|
|
|
|
|
* If there had been a use of the flag register and another CMP using g70
|
|
|
|
|
*
|
|
|
|
|
* add.ge.f0(8) g70<1>F g69<8,8,1>F 4096F
|
|
|
|
|
* (+f0) sel(8) g71<F> g72<8,8,1>F g73<8,8,1>F
|
|
|
|
|
* cmp.ge.f0(8) null g70<8,8,1>F 0F
|
|
|
|
|
*
|
|
|
|
|
* we can recognize that the CMP is generating the flag value that already
|
|
|
|
|
* exists and therefore remove the instruction.
|
2014-08-22 10:54:43 -07:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static bool
|
2016-08-22 15:01:08 -07:00
|
|
|
opt_cmod_propagation_local(const gen_device_info *devinfo, bblock_t *block)
|
2014-08-22 10:54:43 -07:00
|
|
|
{
|
|
|
|
|
bool progress = false;
|
|
|
|
|
int ip = block->end_ip + 1;
|
|
|
|
|
|
|
|
|
|
foreach_inst_in_block_reverse_safe(fs_inst, inst, block) {
|
|
|
|
|
ip--;
|
|
|
|
|
|
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation
Espically on platforms that do not natively generate 0u and ~0u for
Boolean results, we generate a lot of sequences where a CMP is
followed by an AND with 1. emit_bool_to_cond_code does this, for
example. On ILK, this results in a sequence like:
add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F
cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F
and.nz.f0(8) null g3<8,8,1>D 1D
(+f0) iff(8) Jump: 6
The AND.nz is obviously redundant. By propagating the cmod, we can
instead generate
add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F
(+f0) iff(8) Jump: 6
Existing code already handles the propagation from the CMP to the ADD.
Shader-db results:
GM45 (0x2A42):
total instructions in shared programs: 3550829 -> 3550788 (-0.00%)
instructions in affected programs: 10028 -> 9987 (-0.41%)
helped: 24
Iron Lake (0x0046):
total instructions in shared programs: 4993146 -> 4993105 (-0.00%)
instructions in affected programs: 9675 -> 9634 (-0.42%)
helped: 24
Ivy Bridge (0x0166):
total instructions in shared programs: 6291870 -> 6291794 (-0.00%)
instructions in affected programs: 17914 -> 17838 (-0.42%)
helped: 48
Haswell (0x0426):
total instructions in shared programs: 5779256 -> 5779180 (-0.00%)
instructions in affected programs: 16694 -> 16618 (-0.46%)
helped: 48
Broadwell (0x162E):
total instructions in shared programs: 6823088 -> 6823014 (-0.00%)
instructions in affected programs: 15824 -> 15750 (-0.47%)
helped: 46
No chage on Sandy Bridge or on any platform when NIR is used.
v2: Add unit tests suggested by Matt. Remove spurious writes_flag()
check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also
suggested by Matt).
v3: Fix some comments and remove some explicit int() casts in fs_reg
constructors in the unit tests. Both suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
|
|
|
if ((inst->opcode != BRW_OPCODE_AND &&
|
|
|
|
|
inst->opcode != BRW_OPCODE_CMP &&
|
i965/fs: Add support for removing MOV.NZ instructions.
For some reason, we occasionally write the flag register with a MOV.NZ
instruction:
add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F
cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F
mov.nz.f0(8) null g26<8,8,1>D
A MOV.NZ instruction on the result of a CMP is like comparing for
equality with true in C. It's useless. Removing it allows us to
generate:
add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F
total instructions in shared programs: 5955701 -> 5951657 (-0.07%)
instructions in affected programs: 302910 -> 298866 (-1.34%)
GAINED: 1
LOST: 0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
|
|
|
inst->opcode != BRW_OPCODE_MOV) ||
|
2014-08-22 10:54:43 -07:00
|
|
|
inst->predicate != BRW_PREDICATE_NONE ||
|
|
|
|
|
!inst->dst.is_null() ||
|
2015-10-26 17:09:25 -07:00
|
|
|
inst->src[0].file != VGRF ||
|
i965/fs: Add support for removing MOV.NZ instructions.
For some reason, we occasionally write the flag register with a MOV.NZ
instruction:
add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F
cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F
mov.nz.f0(8) null g26<8,8,1>D
A MOV.NZ instruction on the result of a CMP is like comparing for
equality with true in C. It's useless. Removing it allows us to
generate:
add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F
total instructions in shared programs: 5955701 -> 5951657 (-0.07%)
instructions in affected programs: 302910 -> 298866 (-1.34%)
GAINED: 1
LOST: 0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
|
|
|
inst->src[0].abs)
|
|
|
|
|
continue;
|
|
|
|
|
|
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation
Espically on platforms that do not natively generate 0u and ~0u for
Boolean results, we generate a lot of sequences where a CMP is
followed by an AND with 1. emit_bool_to_cond_code does this, for
example. On ILK, this results in a sequence like:
add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F
cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F
and.nz.f0(8) null g3<8,8,1>D 1D
(+f0) iff(8) Jump: 6
The AND.nz is obviously redundant. By propagating the cmod, we can
instead generate
add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F
(+f0) iff(8) Jump: 6
Existing code already handles the propagation from the CMP to the ADD.
Shader-db results:
GM45 (0x2A42):
total instructions in shared programs: 3550829 -> 3550788 (-0.00%)
instructions in affected programs: 10028 -> 9987 (-0.41%)
helped: 24
Iron Lake (0x0046):
total instructions in shared programs: 4993146 -> 4993105 (-0.00%)
instructions in affected programs: 9675 -> 9634 (-0.42%)
helped: 24
Ivy Bridge (0x0166):
total instructions in shared programs: 6291870 -> 6291794 (-0.00%)
instructions in affected programs: 17914 -> 17838 (-0.42%)
helped: 48
Haswell (0x0426):
total instructions in shared programs: 5779256 -> 5779180 (-0.00%)
instructions in affected programs: 16694 -> 16618 (-0.46%)
helped: 48
Broadwell (0x162E):
total instructions in shared programs: 6823088 -> 6823014 (-0.00%)
instructions in affected programs: 15824 -> 15750 (-0.47%)
helped: 46
No chage on Sandy Bridge or on any platform when NIR is used.
v2: Add unit tests suggested by Matt. Remove spurious writes_flag()
check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also
suggested by Matt).
v3: Fix some comments and remove some explicit int() casts in fs_reg
constructors in the unit tests. Both suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
|
|
|
/* Only an AND.NZ can be propagated. Many AND.Z instructions are
|
|
|
|
|
* generated (for ir_unop_not in fs_visitor::emit_bool_to_cond_code).
|
|
|
|
|
* Propagating those would require inverting the condition on the CMP.
|
|
|
|
|
* This changes both the flag value and the register destination of the
|
|
|
|
|
* CMP. That result may be used elsewhere, so we can't change its value
|
|
|
|
|
* on a whim.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->opcode == BRW_OPCODE_AND &&
|
|
|
|
|
!(inst->src[1].is_one() &&
|
|
|
|
|
inst->conditional_mod == BRW_CONDITIONAL_NZ &&
|
|
|
|
|
!inst->src[0].negate))
|
|
|
|
|
continue;
|
|
|
|
|
|
i965/fs: Add support for removing MOV.NZ instructions.
For some reason, we occasionally write the flag register with a MOV.NZ
instruction:
add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F
cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F
mov.nz.f0(8) null g26<8,8,1>D
A MOV.NZ instruction on the result of a CMP is like comparing for
equality with true in C. It's useless. Removing it allows us to
generate:
add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F
total instructions in shared programs: 5955701 -> 5951657 (-0.07%)
instructions in affected programs: 302910 -> 298866 (-1.34%)
GAINED: 1
LOST: 0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
|
|
|
if (inst->opcode == BRW_OPCODE_CMP && !inst->src[1].is_zero())
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (inst->opcode == BRW_OPCODE_MOV &&
|
2015-01-24 04:16:54 -08:00
|
|
|
inst->conditional_mod != BRW_CONDITIONAL_NZ)
|
2014-08-22 10:54:43 -07:00
|
|
|
continue;
|
|
|
|
|
|
2015-01-03 12:18:15 -08:00
|
|
|
bool read_flag = false;
|
2015-10-20 11:16:00 +02:00
|
|
|
foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst, inst) {
|
2016-09-01 19:34:18 -07:00
|
|
|
if (regions_overlap(scan_inst->dst, scan_inst->size_written,
|
|
|
|
|
inst->src[0], inst->size_read(0))) {
|
2014-08-22 10:54:43 -07:00
|
|
|
if (scan_inst->is_partial_write() ||
|
2016-09-01 21:16:14 -07:00
|
|
|
scan_inst->dst.offset != inst->src[0].offset ||
|
2015-08-11 16:16:42 -07:00
|
|
|
scan_inst->exec_size != inst->exec_size)
|
2014-08-22 10:54:43 -07:00
|
|
|
break;
|
|
|
|
|
|
2015-03-17 19:17:15 -07:00
|
|
|
/* CMP's result is the same regardless of dest type. */
|
|
|
|
|
if (inst->conditional_mod == BRW_CONDITIONAL_NZ &&
|
|
|
|
|
scan_inst->opcode == BRW_OPCODE_CMP &&
|
|
|
|
|
(inst->dst.type == BRW_REGISTER_TYPE_D ||
|
|
|
|
|
inst->dst.type == BRW_REGISTER_TYPE_UD)) {
|
|
|
|
|
inst->remove(block);
|
|
|
|
|
progress = true;
|
i965/fs: Handle CMP.nz ... 0 and AND.nz ... 1 similarly in cmod propagation
Espically on platforms that do not natively generate 0u and ~0u for
Boolean results, we generate a lot of sequences where a CMP is
followed by an AND with 1. emit_bool_to_cond_code does this, for
example. On ILK, this results in a sequence like:
add(8) g3<1>F g8<8,8,1>F -g4<0,1,0>F
cmp.l.f0(8) g3<1>D g3<8,8,1>F 0F
and.nz.f0(8) null g3<8,8,1>D 1D
(+f0) iff(8) Jump: 6
The AND.nz is obviously redundant. By propagating the cmod, we can
instead generate
add.l.f0(8) null g8<8,8,1>F -g4<0,1,0>F
(+f0) iff(8) Jump: 6
Existing code already handles the propagation from the CMP to the ADD.
Shader-db results:
GM45 (0x2A42):
total instructions in shared programs: 3550829 -> 3550788 (-0.00%)
instructions in affected programs: 10028 -> 9987 (-0.41%)
helped: 24
Iron Lake (0x0046):
total instructions in shared programs: 4993146 -> 4993105 (-0.00%)
instructions in affected programs: 9675 -> 9634 (-0.42%)
helped: 24
Ivy Bridge (0x0166):
total instructions in shared programs: 6291870 -> 6291794 (-0.00%)
instructions in affected programs: 17914 -> 17838 (-0.42%)
helped: 48
Haswell (0x0426):
total instructions in shared programs: 5779256 -> 5779180 (-0.00%)
instructions in affected programs: 16694 -> 16618 (-0.46%)
helped: 48
Broadwell (0x162E):
total instructions in shared programs: 6823088 -> 6823014 (-0.00%)
instructions in affected programs: 15824 -> 15750 (-0.47%)
helped: 46
No chage on Sandy Bridge or on any platform when NIR is used.
v2: Add unit tests suggested by Matt. Remove spurious writes_flag()
check on scan_inst when scan_inst is known to be BRW_OPCODE_CMP (also
suggested by Matt).
v3: Fix some comments and remove some explicit int() casts in fs_reg
constructors in the unit tests. Both suggested by Matt.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 21:12:28 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-17 19:17:15 -07:00
|
|
|
/* If the AND wasn't handled by the previous case, it isn't safe
|
|
|
|
|
* to remove it.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->opcode == BRW_OPCODE_AND)
|
|
|
|
|
break;
|
|
|
|
|
|
2015-02-27 10:22:21 -08:00
|
|
|
/* Comparisons operate differently for ints and floats */
|
2015-03-26 10:09:54 -07:00
|
|
|
if (scan_inst->dst.type != inst->dst.type &&
|
|
|
|
|
(scan_inst->dst.type == BRW_REGISTER_TYPE_F ||
|
|
|
|
|
inst->dst.type == BRW_REGISTER_TYPE_F))
|
2015-02-27 10:22:21 -08:00
|
|
|
break;
|
|
|
|
|
|
2015-01-24 04:16:54 -08:00
|
|
|
/* If the instruction generating inst's source also wrote the
|
|
|
|
|
* flag, and inst is doing a simple .nz comparison, then inst
|
|
|
|
|
* is redundant - the appropriate value is already in the flag
|
|
|
|
|
* register. Delete inst.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->conditional_mod == BRW_CONDITIONAL_NZ &&
|
|
|
|
|
!inst->src[0].negate &&
|
2016-05-18 22:40:40 -07:00
|
|
|
scan_inst->flags_written()) {
|
i965/fs: Add support for removing MOV.NZ instructions.
For some reason, we occasionally write the flag register with a MOV.NZ
instruction:
add(8) g25<1>F -g6<0,1,0>F g15<8,8,1>F
cmp.l.f0(8) g26<1>D g25<8,8,1>F 0F
mov.nz.f0(8) null g26<8,8,1>D
A MOV.NZ instruction on the result of a CMP is like comparing for
equality with true in C. It's useless. Removing it allows us to
generate:
add.l.f0(8) null -g6<0,1,0>F g15<8,8,1>F
total instructions in shared programs: 5955701 -> 5951657 (-0.07%)
instructions in affected programs: 302910 -> 298866 (-1.34%)
GAINED: 1
LOST: 0
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-12-30 17:19:41 -08:00
|
|
|
inst->remove(block);
|
|
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-25 15:39:29 -07:00
|
|
|
/* The conditional mod of the CMP/CMPN instructions behaves
|
|
|
|
|
* specially because the flag output is not calculated from the
|
|
|
|
|
* result of the instruction, but the other way around, which
|
|
|
|
|
* means that even if the condmod to propagate and the condmod
|
|
|
|
|
* from the CMP instruction are the same they will in general give
|
|
|
|
|
* different results because they are evaluated based on different
|
|
|
|
|
* inputs.
|
|
|
|
|
*/
|
|
|
|
|
if (scan_inst->opcode == BRW_OPCODE_CMP ||
|
|
|
|
|
scan_inst->opcode == BRW_OPCODE_CMPN)
|
|
|
|
|
break;
|
2017-10-04 13:49:29 -07:00
|
|
|
|
|
|
|
|
/* From the Sky Lake PRM Vol. 7 "Assigning Conditional Mods":
|
|
|
|
|
*
|
|
|
|
|
* * Note that the [post condition signal] bits generated at
|
|
|
|
|
* the output of a compute are before the .sat.
|
|
|
|
|
*/
|
|
|
|
|
if (scan_inst->saturate)
|
|
|
|
|
break;
|
2017-10-04 13:20:52 -07:00
|
|
|
|
|
|
|
|
/* From the Sky Lake PRM, Vol 2a, "Multiply":
|
|
|
|
|
*
|
|
|
|
|
* "When multiplying integer data types, if one of the sources
|
|
|
|
|
* is a DW, the resulting full precision data is stored in
|
|
|
|
|
* the accumulator. However, if the destination data type is
|
|
|
|
|
* either W or DW, the low bits of the result are written to
|
|
|
|
|
* the destination register and the remaining high bits are
|
|
|
|
|
* discarded. This results in undefined Overflow and Sign
|
|
|
|
|
* flags. Therefore, conditional modifiers and saturation
|
|
|
|
|
* (.sat) cannot be used in this case."
|
|
|
|
|
*
|
|
|
|
|
* We just disallow cmod propagation on all integer multiplies.
|
|
|
|
|
*/
|
|
|
|
|
if (!brw_reg_type_is_floating_point(scan_inst->dst.type) &&
|
|
|
|
|
scan_inst->opcode == BRW_OPCODE_MUL)
|
|
|
|
|
break;
|
2016-04-25 15:39:29 -07:00
|
|
|
|
2015-01-24 04:16:54 -08:00
|
|
|
/* Otherwise, try propagating the conditional. */
|
2014-12-30 12:18:57 -08:00
|
|
|
enum brw_conditional_mod cond =
|
|
|
|
|
inst->src[0].negate ? brw_swap_cmod(inst->conditional_mod)
|
|
|
|
|
: inst->conditional_mod;
|
|
|
|
|
|
2014-08-22 10:54:43 -07:00
|
|
|
if (scan_inst->can_do_cmod() &&
|
2015-01-03 12:18:15 -08:00
|
|
|
((!read_flag && scan_inst->conditional_mod == BRW_CONDITIONAL_NONE) ||
|
2014-12-30 12:18:57 -08:00
|
|
|
scan_inst->conditional_mod == cond)) {
|
|
|
|
|
scan_inst->conditional_mod = cond;
|
2014-08-22 10:54:43 -07:00
|
|
|
inst->remove(block);
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-18 22:40:40 -07:00
|
|
|
if (scan_inst->flags_written())
|
2014-08-22 10:54:43 -07:00
|
|
|
break;
|
2015-01-03 12:18:15 -08:00
|
|
|
|
2016-05-18 22:40:40 -07:00
|
|
|
read_flag = read_flag || scan_inst->flags_read(devinfo);
|
2014-08-22 10:54:43 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return progress;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
|
fs_visitor::opt_cmod_propagation()
|
|
|
|
|
{
|
|
|
|
|
bool progress = false;
|
|
|
|
|
|
|
|
|
|
foreach_block_reverse(block, cfg) {
|
2016-05-18 22:40:40 -07:00
|
|
|
progress = opt_cmod_propagation_local(devinfo, block) || progress;
|
2014-08-22 10:54:43 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (progress)
|
|
|
|
|
invalidate_live_intervals();
|
|
|
|
|
|
|
|
|
|
return progress;
|
|
|
|
|
}
|