[Mesa-dev] [PATCH 5/5] gallivm: enable stores of integer types.

Jose Fonseca jfonseca at vmware.com
Tue Feb 7 07:37:04 PST 2012



----- Original Message -----
> On Mon, Feb 6, 2012 at 9:01 PM, Jose Fonseca <jfonseca at vmware.com>
> wrote:
> > ----- Original Message -----
> >> On Mon, Feb 6, 2012 at 7:47 PM, Jose Fonseca <jfonseca at vmware.com>
> >> wrote:
> >> > Dave,
> >> >
> >> > I really see no point of inferring anything when translating
> >> > MOVs.
> >> > The src/dst value will need to be converted from/to a floating
> >> > point anyway so this is unnecessary complexity AFAICS. If you
> >> > believe this is really necessary please provide a concrete
> >> > example.
> >>
> >> The problem is MOV from immediate, since immediates are stored as
> >> the
> >> correct internal type, so we don't get to infer the src in that
> >> case,
> >> then we try to MOV int4* to float4* and llvm crashes.
> >
> > I see.
> >
> > In that case I'd suggest you to:
> >
> > - in lp_emit_immediate_soa() bitcast _all_ integer immediates to
> > floats (i.e., bld->immediates[] is always of llvm type float, just
> > like bld->temps[], and bld->outputs[], etc.).
> >
> > - in emit_fetch_immediate() bitcast back to integer when stype ==
> > INT or UINT
> 
> I've started looking at this, but it means we have to change
> immediates from being constants to being something we can bitcast. At
> the moment the immediate fetch just fetches one immediate value from
> a
> vector, not a pointer to an immediate value, making this pointer
> based
> just seems like an unnecessary step and seems to be like it will get
> in the way of optimisations that can work on constant values.

If you use LLVMConstBitCast() the result is a still a constant.  Nothing is lost.

Jose


More information about the mesa-dev mailing list