[Mesa-dev] [PATCH] nvc0/lowering: Handle conversions to U64/S64 manually
Pierre Moreau
pierre.morrow at free.fr
Sat Mar 19 22:52:10 UTC 2016
On 06:41 PM - Mar 19 2016, Ilia Mirkin wrote:
> On Sat, Mar 19, 2016 at 6:36 PM, Pierre Moreau <pierre.morrow at 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.morrow at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160319/ef016f78/attachment.sig>
More information about the mesa-dev
mailing list