This is an archive of the discontinued LLVM Phabricator instance.

[NVPTX] Add an "image" attribute and simplify the NVPTX rdoimage, wroimage, and rdrwimage attributes.
Needs ReviewPublic

Authored by brianagrace on Mar 6 2017, 3:47 PM.

Details

Reviewers
jlebar
Summary

This is the first in a series of patches to simplify the way NVPTX attaches metadata to functions, function arguments, and global variables. Currently all NVPTX metadata is found via the !nvvm.annotations module-level metadata. This means that reading metadata for one function, argument, or global variable requires iterating over *all* of the module's NVPTX metadata. (We have a janky, global cache that attempts to fix this, but doesn't really succeed.)

We aim to incrementally change the NVPTX metadata format so that our annotations are attached to the objects they describe. This will simplify the format and obviate the need for the cache.

NVPTX has the notion of "image" arguments to kernel functions. These correspond to the .surfref and .texref argument annotations [1], and whether or not an argument is an image is used in NVPTXImageOptimizer. An image argument may be either read-only, read-write, or write-only. This patch:

  • Adds an LLVM "image" attribute,
  • Lets us mark non-pointers as read-only / write-only (images can be i64s), and
  • Changes the NVPTX "isImage" functions to recognize the new format, e.g. "define void @foo(i64 readonly image %img)".

[1] http://docs.nvidia.com/cuda/parallel-thread-execution/#texture-sampler-and-surface-types

Diff Detail

Event Timeline

brianagrace created this revision.Mar 6 2017, 3:47 PM
brianagrace edited the summary of this revision. (Show Details)Mar 6 2017, 3:47 PM
brianagrace edited the summary of this revision. (Show Details)
    • Added new Image attribute
    • Had to change readonly attribute to apply to types other than pointers - not sure if that's a good idea
  • Still have to update llvm documentation
brianagrace edited the summary of this revision. (Show Details)Mar 7 2017, 10:28 AM
jlebar edited edge metadata.EditedMar 7 2017, 10:53 AM

We should elaborate more in the patch description with respect to (a) what we're changing (may need to describe the current and new state) and (b) why we're changing it. We should also pay special attention to the first line of the patch description (I think in phab it's the "title") because that's all some people will see.

Maybe something like:

[NVPTX] Add an "image" attribute and simplify the NVPTX rdoimage, wroimage, and rdrwimage attributes.

This is the first in a series of patches to simplify the way NVPTX attaches metadata to functions, function arguments, and global variables. Currently all NVPTX metadata is found via the !nvvm.annotations module-level metadata. This means that reading metadata for one function, argument, or global variable requires iterating over *all* of the module's NVPTX metadata. (We have a janky, global cache that attempts to fix this, but doesn't really succeed.)

We aim to incrementally change the NVPTX metadata format so that our annotations are attached to the objects they describe. This will simplify the format and obviate the need for the cache.

NVPTX has the notion of "image" arguments to kernel functions. These correspond to the .surfref and .texref argument annotations [1], and whether or not an argument is an image is used in NVPTXImageOptimizer. An image argument may be either read-only, read-write, or write-only. This patch:

  • adds an LLVM "image" attribute,
  • lets us mark non-pointers as read-only / write-only (images can be i64s), and
  • changes the NVPTX "isImage" functions to recognize the new format, e.g. "define void @foo(i64 readonly image %img)".

[1] http://docs.nvidia.com/cuda/parallel-thread-execution/#texture-sampler-and-surface-types

include/llvm/IR/Attributes.td
48

Update comment?

brianagrace marked an inline comment as done.
brianagrace retitled this revision from Use read only/write only attributes to [NVPTX] Add an "image" attribute and simplify the NVPTX rdoimage, wroimage, and rdrwimage attributes..
brianagrace edited the summary of this revision. (Show Details)
  • List Item

Be sure to add llvm-commits when creating phab reviews, otherwise the mailing list won't see it and people will be sad. (I have no idea why we cannot do this automatically.)

jlebar added subscribers: tra, arsenm.Mar 7 2017, 6:35 PM
jlebar added inline comments.
include/llvm/IR/Attributes.td
48

@tra @arsenm, Do you think we should call this "texref", "textureref" or something? AFAICT what nvptx calls an "image" really means "a texture or surface ref", where the difference between texture and surface refs is that surface refs are writable.

lib/Target/NVPTX/NVPTXUtilities.cpp
-17

Probably didn't mean to make this change?

177

Need to check that it's also an image?

test/CodeGen/NVPTX/surf-read.ll
20

(Just as an example of how messed up this old metadata format is: Apparently "i32 0" here means that this *is* an image? Like, it looks like it's saying "false"!)

jlebar added a comment.Mar 7 2017, 6:36 PM

An earlier commit description had said that you needed to make readonly /writeonly work on non-pointer types -- is that change still necessary? I expect it will be somewhat controversial...

tra added a comment.Mar 7 2017, 6:48 PM

I'd say texref. CUDA appears to shorten it this way in the driver API where we have number of functions with cuTexRef prefix.

arsenm added a comment.Mar 7 2017, 9:10 PM

What advantage over reserving an address space for images does this have? Now that we can have non-integral pointer types, why not just designate an address space for read/write images?

jlebar added a comment.Mar 7 2017, 9:25 PM

What advantage over reserving an address space for images does this have? Now that we can have non-integral pointer types, why not just designate an address space for read/write images?

Hm, I guess that makes a lot of sense... I don't think it's legal to GEP, address space cast, or even do regular loads on these pointers, but whatever?

I'm a bit concerned that making this change will require changing all of the NVPTX texture and surface intrinsics, which is kind of a tall order and may have add-on consequences. Is there a reasonable intermediate state?

Maybe we should just drop support for image args to kernels until we have a frontend which uses this. It seems like otherwise, if we make a big change, we're somewhat likely to have to make another big change when we actually add front-end support.

WDYT?

brianagrace updated this revision to Diff 91071.Mar 8 2017, 2:27 PM
brianagrace marked 2 inline comments as done.

Adressing comments

test/CodeGen/NVPTX/surf-read.ll
20

Its the argument number - the 0th arg of the function is an image

arsenm added a comment.Mar 8 2017, 2:31 PM

What advantage over reserving an address space for images does this have? Now that we can have non-integral pointer types, why not just designate an address space for read/write images?

Hm, I guess that makes a lot of sense... I don't think it's legal to GEP, address space cast, or even do regular loads on these pointers, but whatever?

I think these are allowed, just not ptrtoint

brianagrace marked an inline comment as not done.Mar 8 2017, 2:34 PM