i965/ir: Update several stale comments.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

src/mesa/drivers/dri/i965/brw_defines.h

@@ -1010,7 +1010,7 @@ enum opcode {
     * For example, parameters for a send-from-GRF message.  Or, updating
     * channels of a size 4 VGRF used to store vec4s such as texturing results.
     *
-    * This will be lowered into MOVs from each source to consecutive reg_offsets
+    * This will be lowered into MOVs from each source to consecutive offsets
     * of the destination VGRF.
     *
     * src[0] may be BAD_FILE.  If so, the lowering pass skips emitting the MOV,

src/mesa/drivers/dri/i965/brw_fs.cpp

@@ -172,12 +172,12 @@ fs_visitor::VARYING_PULL_CONSTANT_LOAD(const fs_builder &bld,
     * be any component of a vector, and then we load 4 contiguous
     * components starting from that.
     *
-    * We break down the const_offset to a portion added to the variable
-    * offset and a portion done using reg_offset, which means that if you
-    * have GLSL using something like "uniform vec4 a[20]; gl_FragColor =
-    * a[i]", we'll temporarily generate 4 vec4 loads from offset i * 4, and
-    * CSE can later notice that those loads are all the same and eliminate
-    * the redundant ones.
+    * We break down the const_offset to a portion added to the variable offset
+    * and a portion done using fs_reg::offset, which means that if you have
+    * GLSL using something like "uniform vec4 a[20]; gl_FragColor = a[i]",
+    * we'll temporarily generate 4 vec4 loads from offset i * 4, and CSE can
+    * later notice that those loads are all the same and eliminate the
+    * redundant ones.
     */
    fs_reg vec4_offset = vgrf(glsl_type::uint_type);
    bld.ADD(vec4_offset, varying_offset, brw_imm_ud(const_offset & ~0xf));
@@ -2062,7 +2062,7 @@ fs_visitor::assign_constant_locations()
    stage_prog_data->nr_params = num_push_constants;
    stage_prog_data->nr_pull_params = num_pull_constants;
 
-   /* Up until now, the param[] array has been indexed by reg + reg_offset
+   /* Up until now, the param[] array has been indexed by reg + offset
     * of UNIFORM registers.  Move pull constants into pull_param[] and
     * condense param[] to only contain the uniforms we chose to push.
     *
@@ -3166,10 +3166,6 @@ fs_visitor::insert_gen4_send_dependency_workarounds()
 
    bool progress = false;
 
-   /* Note that we're done with register allocation, so GRF fs_regs always
-    * have a .reg_offset of 0.
-    */
-
    foreach_block_and_inst(block, fs_inst, inst, cfg) {
       if (inst->mlen != 0 && inst->dst.file == VGRF) {
          insert_gen4_pre_send_dependency_workarounds(block, inst);

src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp

@@ -41,12 +41,12 @@ using namespace brw;
  * but we currently do not.  It is easier for the consumers of this
  * information to work with whole VGRFs.
  *
- * However, we internally track use/def information at the per-component
- * (reg_offset) level for greater accuracy.  Large VGRFs may be accessed
- * piecemeal over many (possibly non-adjacent) instructions.  In this case,
- * examining a single instruction is insufficient to decide whether a whole
- * VGRF is ultimately used or defined.  Tracking individual components
- * allows us to easily assemble this information.
+ * However, we internally track use/def information at the per-GRF level for
+ * greater accuracy.  Large VGRFs may be accessed piecemeal over many
+ * (possibly non-adjacent) instructions.  In this case, examining a single
+ * instruction is insufficient to decide whether a whole VGRF is ultimately
+ * used or defined.  Tracking individual components allows us to easily
+ * assemble this information.
  *
  * See Muchnick's Advanced Compiler Design and Implementation, section
  * 14.1 (p444).

src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp

@@ -1489,10 +1489,10 @@ fs_instruction_scheduler::choose_instruction_to_schedule()
             if (v->devinfo->gen < 7) {
                fs_inst *chosen_inst = (fs_inst *)chosen->inst;
 
-               /* We use regs_written > 1 as our test for the kind of send
-                * instruction to avoid -- only sends generate many regs, and a
-                * single-result send is probably actually reducing register
-                * pressure.
+               /* We use size_written > 4 * exec_size as our test for the kind
+                * of send instruction to avoid -- only sends generate many
+                * regs, and a single-result send is probably actually reducing
+                * register pressure.
                 */
                if (inst->size_written <= 4 * inst->exec_size &&
                    chosen_inst->size_written > 4 * chosen_inst->exec_size) {

src/mesa/drivers/dri/i965/brw_vec4.cpp

@@ -1321,10 +1321,10 @@ vec4_visitor::eliminate_find_live_channel()
  * Splits virtual GRFs requesting more than one contiguous physical register.
  *
  * We initially create large virtual GRFs for temporary structures, arrays,
- * and matrices, so that the dereference visitor functions can add reg_offsets
- * to work their way down to the actual member being accessed.  But when it
- * comes to optimization, we'd like to treat each register as individual
- * storage if possible.
+ * and matrices, so that the visitor functions can add offsets to work their
+ * way down to the actual member being accessed.  But when it comes to
+ * optimization, we'd like to treat each register as individual storage if
+ * possible.
  *
  * So far, the only thing that might prevent splitting is a send message from
  * a GRF on IVB.