Am 16.10.19 um 01:20 schrieb Dave Airlie: > 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. You mean the signed sse2/avx2 intrinsics for psub/padd? At a quick glance it seems like llvm 8 actually already removed both the signed and unsigned intrinsics in the end (initially only the unsigned versions were removed, which is a lot more noticeable as it is hit basically in all tests). I think the llvm specific intrinsics should work in llvm 8 too. I'll test this...
Roland > > 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
