[PATCH] D39026: [NVPTX] allow address space inference for volatile loads/stores.
Artem Belevich via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 23 15:21:08 PDT 2017
tra marked 2 inline comments as done.
tra added inline comments.
================
Comment at: llvm/include/llvm/Analysis/TargetTransformInfo.h:495
+ /// instruction) has volatile variant. If that's the case then we can avoid
+ /// addrspacecast to generic AS for volatile loads/stores.
+ bool hasVolatileVariant(Instruction *I, unsigned AddrSpace) const;
----------------
jlebar wrote:
> I'm not sure this second sentence helps much -- it feels sort of apropos of nothing to me here.
>
> Maybe we should say something to cover the fact that if this returns false, the instruction may still have a volatile variant -- we might simply not have implemented this TTI function for that target. :)
Rephrased. PTAL.
================
Comment at: llvm/test/CodeGen/NVPTX/ld-st-addrrspace.py:59
+ [True, False],
+ ["", ".shared", ".global", ".const", ".local", ".param"]):
+
----------------
jlebar wrote:
> I'm not sure it's clearer, but ftr we could get rid of the three maps by doing
>
> ```
> for (llvm_type, ptx_type), (llvm_addrspace, ptx_addrspace), volatile in product(
> [("i8", "u8"), ...], [(0, ""), (1, ".global"), ...], [True, False]):
> ```
>
> At least I'd recommend getting rid of get_as_id, since it's inconsistent with how we do the other two maps.
Fixed as_id.
Folding three maps into a single statement is a bit too much python-fu, IMO.
https://reviews.llvm.org/D39026
More information about the llvm-commits
mailing list