On Thu, Nov 9, 2017 at 7:17 PM, Marek Olšák <mar...@gmail.com> wrote: > On Fri, Nov 10, 2017 at 12:40 AM, Matt Arsenault <arse...@gmail.com> wrote: >> >>> On Nov 10, 2017, at 07:41, Marek Olšák <mar...@gmail.com> wrote: >>> >>> Hi, >>> >>> This fixes the TCS gl_ClipDistance piglit failure that was uncovered >>> by a recent LLVM change. The solution is to set volatile on loads >>> and stores to enforce proper ordering. >>> >>> Please review. >>> >> >> >> Every LDS access certainly should not be volatile. This kills all >> optimizations, like formation of ds_read2_b32. What ordering issue are you >> having? > > It might be caused by inttoptr(NULL) that we do to declare LDS. There > is simply no ordering enforced, which is weird.
As soon as you do inttoptr(NULL), you've generated a poison value (in LLVM legalese), so LLVM will assume that you never dereference it and optimize accordingly. I think a GEP instruction without the inbounds parameter set will get rid of the poison value, although I'm not sure about the case where the offset is known to be zero. At least, that's my reading of the langref text for the GEP instruction (https://llvm.org/docs/LangRef.html#id215). If zero is a valid address in LDS, then it sounds like LLVM needs to be fixed to disable this optimization for certain address spaces. On the other hand, if you're doing inttoptr(NULL) + offset, where "offset" is the result of a ptrtoint somewhere, you should be doing inttoptr(offset) instead, and then LLVM should never misbehave. > > This series only sets volatile on HS output loads and stores. Compute > shaders and other uses don't set volatile. > > Marek > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
