[Mesa-dev] [PATCH] gallivm: use fallback code for mul_hi with llvm >= 7.0

Dave Airlie airlied at gmail.com
Tue Oct 15 23:20:56 UTC 2019


On Fri, 30 Aug 2019 at 00:55, Roland Scheidegger <sroland at vmware.com> wrote:
>
> Am 29.08.19 um 15:05 schrieb Jose Fonseca:
> > This change is
> >
> >   Reviewed-by: Jose Fonseca <jfonseca at vmware.com>
> >
> > Regarding follow up change, do you think the LLVM pattern is sane/doable?
> Yes, should be doable and not too bad (I did not verify that what we're
> doing doesn't actually get recognized, since it's theoretically possible
> some other lowering could produce the pattern, although it seems unlikely).
> I think though this code isn't hit a lot - it was once used by draw,
> which is why I noticed the suboptimal code generated and added the
> optimized version, but nowadays it's just for mulhi, so should be fairly
> rare in practice.
>
>
> >
> > If not we should try ask them to reconsider relying strictly upon
> > pattern matching.  I get the feeling upstream LLVM is throwing the baby
> > with the water with these changes.  I do understand the advantages of
> > moving away from vendor specific intrinsics, but I think that for things
> > which have no natural representation on LLVM base IR, they should add a
> > vendor-agnostic intrinsic, for example a new "/llvm.mulhi.*"  set of
> > instrinsics/, as narrow pattern matching is bound to produce performance
> > cliffs nobody will notice.
> They did add new generic intrinsics for some things, but not this one
> indeed.
> I'm not exactly a big fan of this pattern matching in favor of
> intrinsics neither, at least if the patterns are non-trivial...

Btw In working on something else, I found the padd and psub intrinsic
paths seem to fail at least on LLVM 8.

I don't have an example test to show though.

Dave.


More information about the mesa-dev mailing list