I'll throw together a patch to make nir_src_copy take pointers to keep
things consistent.
Reviewed-by: Jason Ekstrand <jason.ekstr...@intel.com>
On Thu, Jan 22, 2015 at 11:08 AM, Eric Anholt <e...@anholt.net> wrote:
> Jason Ekstrand <ja...@jlekstrand.net> writes:
>
> > On Wed, Jan 21, 2015 at 5:26 PM, Eric Anholt <e...@anholt.net> wrote:
> >
> >> There aren't many users yet, but I wanted to do this from my scalarizing
> >> pass.
> >> ---
> >> src/glsl/nir/nir.c | 18 ++++++++++++++++++
> >> src/glsl/nir/nir.h | 5 ++++-
> >> src/glsl/nir/nir_lower_vec_to_movs.c | 7 ++-----
> >> src/glsl/nir/nir_opt_peephole_select.c | 5 +----
> >> 4 files changed, 25 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
> >> index 16ad2da..e414df9 100644
> >> --- a/src/glsl/nir/nir.c
> >> +++ b/src/glsl/nir/nir.c
> >> @@ -175,6 +175,24 @@ nir_dest nir_dest_copy(nir_dest dest, void
> *mem_ctx)
> >> return ret;
> >> }
> >>
> >> +void
> >> +nir_alu_src_copy(nir_alu_src *dest, nir_alu_src *src, void *mem_ctx)
> >> +{
> >>
> >
> > We already have nir_src_copy which returns a nir_src instead of taking a
> > pointer. TBH, I'm not sure which I prefer, but it would be good to be
> > consistent. Thoughts?
>
> Yeah, I was thinking that as the struct gets bigger, passing it around
> on the stack gets worse. For API consistency, I think that would mean
> pointers for both.
>
> >> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> >> index 8dc5222..7f0aa36 100644
> >> --- a/src/glsl/nir/nir.h
> >> +++ b/src/glsl/nir/nir.h
> >> @@ -569,7 +569,10 @@ typedef struct {
> >> unsigned write_mask : 4; /* ignored if dest.is_ssa is true */
> >> } nir_alu_dest;
> >>
> >> -#define OPCODE(name, num_inputs, output_size, output_type, \
> >> +void nir_alu_src_copy(nir_alu_src *dest, nir_alu_src *src, void
> *mem_ctx);
> >> +void nir_alu_dest_copy(nir_alu_dest *dest, nir_alu_dest *src, void
> >> *mem_ctx);
> >> +
> >> +#define OPCODE(name, num_inputs, output_size, output_type, \
> >>
> >
> > Accidental whitespace change?
>
> Not sure how that happened, will fix.
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
