On Fri, 30 Aug 2019 at 00:55, Roland Scheidegger <srol...@vmware.com> wrote: > > Am 29.08.19 um 15:05 schrieb Jose Fonseca: > > This change is > > > > Reviewed-by: Jose Fonseca <jfons...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
