aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/InitPreprocessor.cpp
diff options
context:
space:
mode:
authorMatt Arsenault <Matthew.Arsenault@amd.com>2014-09-15 16:48:01 +0000
committerMatt Arsenault <Matthew.Arsenault@amd.com>2014-09-15 16:48:01 +0000
commit72aafd06891e1c01498c416f7b1d9ad9ad131486 (patch)
tree997100213ae1bd6ddf6f78b214fb73ffecce6a82 /clang/lib/Frontend/InitPreprocessor.cpp
parent5388538e8724ddbf1bbebde68fe456507cb2826e (diff)
downloadllvm-72aafd06891e1c01498c416f7b1d9ad9ad131486.zip
llvm-72aafd06891e1c01498c416f7b1d9ad9ad131486.tar.gz
llvm-72aafd06891e1c01498c416f7b1d9ad9ad131486.tar.bz2
R600/SI: Add some mubuf testcases.
I noticed some odd looking cases where addr64 wasn't set when storing to a pointer in an SGPR. This seems to be intentional, and partially tested already. The documentation seems to describe addr64 in terms of which registers addressing modifiers come from, but I would expect to always need addr64 when using 64-bit pointers. If no offset is applied, it makes sense to not need to worry about doing a 64-bit add for the final address. A small immediate offset can be applied, so is it OK to not have addr64 set if a carry is necessary when adding the base pointer in the resource to the offset? llvm-svn: 217785
Diffstat (limited to 'clang/lib/Frontend/InitPreprocessor.cpp')
0 files changed, 0 insertions, 0 deletions