Like with the predicate fields before, there's no need to use the full
instruction to collect the list of options. This allows us to decouple
the list of options from a specific instruction encoding.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Rather than user a full instruction for that. Also use
set_instruction_predicate() for a case that coud not be done like that
before the refactoring (because everyone now uses the same instruction
structure).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Now that all instructions (relocatable or not) are struct
brw_program_instructions, this means we can move the relocation specific
information out the "relocatable instruction" structure. This will allow
us to share the relocation information between different types of
instructions.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This will be less typing for the refactoring to come (which is use
struct brw_program_instruction in gram.y for the type of all the
instructions).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The list of region restrictions in bspec do say that we can't have:
width == 1 && hstrize != 0
We do have plenty of assembly code that don't respect that behaviour. So
let's hide the warning under a -W flag (for now) while we fix things.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Now that we have locations, we can write error() and warn() functions
giving more information about where it's going wrong.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
A few notes:
I needed to introduce a brw context and compile structs. These are only
used to get which generation we are compiling code for, but eventually
we can use more of the infrastructure.
brw_set_dest() uses the destination register width to program the
instruction execution size.
The assembler can either take subnr in bytes or in number of elements,
so we need a resolve step when setting a brw_reg.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
One more step on the road to replacing all register-like structures by
struct brw_reg.
Two things in this commit are worth noting:
* As we are using more and more brw_reg, a lot of the field-by-field
assignments can be replaced by 1 assignment which results is a
reduction of code
* As the destination horizontal stride is now stored on 2 bits in
brw_reg, it's not possible to defer the handling of DEFAULT_DSTREGION
(aka (int)-1) when setting the destination operand. It has to be done
when parsing the region and resolve_dst_region() is a helper for that
task.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
More code simplification can be layered on top of that (by using some
brw_* helpers to create registers), that'd be for another commit.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
More code simplification can be layered on top of that (by using some
brw_* helpers to create registers), that'd be for another commit.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
It's time to start converting the emission code in gram.y to use libbrw
infrastructure. Let's start with using brw_reg for declared register.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Until now, the assembler had relocation-related fields added to struct
brw_instruction. This changes the size of the structure and break code
assuming the opcode structure is really 16 bytes, for instance the
emission code in brw_eu_emit.c.
With this commit, we build on the infrastructure that slowly emerged in
the few previous commits to add a relocatable instruction with the
needed fields.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The output of the parsing is a list of struct brw_program_instruction.
These instructions can be either GEN instructions aka struct
brw_instruction or labels. To make this more explicit we now have a type
to test to determine which instruction we are dealing with.
This will also allow to to pull the relocation bits into struct
brw_program_instruction instead of having them in the structure
representing the opcodes.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Another step towards using struct brw_reg for source and destination
operands.
Instead of having a separate field to store the sub register number of
the address register in indirect access mode, we can reuse the subreg_nr
field that was only used for direct access so far.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
writemask_set gets in the way of switching to using struct brw_reg and
it's possible to derive it from the writemask value.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
From Mesa. This imports a bit more the of brw_eu* infrastructure (which
is going towards the right direction!) from mesa and the update is quite
a significant improvement over what we had.
I also verified that the changes that were done on the assembler old
version of brw_disasm.c were already supported by the Mesa version, and
indeed they were.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This involved changing dest operands to have their own structure like src
operands, as the destination writemask (which is align16-only) shares space
with register numbers in align1 mode.
This required restructuring to store source operands in a new structure rather
than being stored in instructions, as swizzle is align16-only and shares
storage with other fields for align1 mode.
These changes were not tested on real programs using swizzle.
