On 06:41 PM - Mar 19 2016, Ilia Mirkin wrote:
> On Sat, Mar 19, 2016 at 6:36 PM, Pierre Moreau <pierre.mor...@free.fr> wrote:
> > On 06:26 PM - Mar 19 2016, Ilia Mirkin wrote:
> >> On Sat, Mar 19, 2016 at 6:26 PM, Pierre Moreau <pierre.mor...@free.fr> 
> >> wrote:
> >> > However, you could have some `long bar; char foo = 
> >> > convert_char_sat(bar);` in
> >> > the OpenCL kernel.
> >>
> >> Sure, but the SPIR-V -> nv50/ir converter could be smarter about when
> >> it generates the converts, no?
> >
> > It should be possible, but then I'm unsure what ends up in the SPIR-V ->
> > nv50/ir converter and what ends up in the nv50/ir backend. Should I also do
> > constant folding in the converter? I was assuming the backend would take 
> > care
> > of the optimisations, removing useless converts, but maybe my assumptions 
> > were
> > wrong and I have to take care of more things than just translating from 
> > SPIR-V
> > to nv50/ir?
> 
> Well, the nv50 ir is not a well-specified IR. So it's kind of up to us
> what to do. However if the hw hates converts with src/dst types like
> that, I'm perfectly happy to decree that such converts shall never
> make it into the IR. That said, if you feel strongly about it, we can
> leave it as a fix-up pass. What about nv50, need the same logic there
> too right?

If such converts are not permitted in nv50/ir, then that means each converter
to nv50/ir will need to do the fixup themselves, resulting in, most likely,
duplicate code between them, as they will handle it more or less the same way.
(Well, there aren't many converters to nv50/ir, so not really a big issue
here.) Whereas if we have it as a fixup pass, we need the code only once, and
have it handled for all existing (and future) converters.
But you have way more experience with nv50/ir and compilers than I have, so,
your call.

Most likely, but I haven't tried it. I should probably have this code in an
earlier pass then, that is not family dependent.

Pierre

> 
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Attachment: signature.asc
Description: PGP signature

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to