aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Lex/ModuleMap.cpp
diff options
context:
space:
mode:
authorMatt Arsenault <Matthew.Arsenault@amd.com>2018-03-29 21:30:06 +0000
committerMatt Arsenault <Matthew.Arsenault@amd.com>2018-03-29 21:30:06 +0000
commit03ae399d50890edd031f8d889a10fa36cee8d101 (patch)
tree0c04c7a253603c951701b47d08099ebfd07f9a42 /clang/lib/Lex/ModuleMap.cpp
parent50635dab263c96a8b8ccde24f2fc09ceffe5ef20 (diff)
downloadllvm-03ae399d50890edd031f8d889a10fa36cee8d101.zip
llvm-03ae399d50890edd031f8d889a10fa36cee8d101.tar.gz
llvm-03ae399d50890edd031f8d889a10fa36cee8d101.tar.bz2
AMDGPU: Support realigning stack
While the stack access instructions don't care about alignment > 4, some transformations on the pointer calculation do make assumptions based on knowing the low bits of a pointer are 0. If a stack object ends up being accessed through its absolute address (relative to the kernel scratch wave offset), the addressing expression may depend on the stack frame being properly aligned. This was breaking in a testcase due to the add->or combine. I think some of the SP/FP handling logic is still backwards, and overly simplistic to support all of the stack features. Code which tries to modify the SP with inline asm for example or variable sized objects will probably require redoing this. llvm-svn: 328831
Diffstat (limited to 'clang/lib/Lex/ModuleMap.cpp')
0 files changed, 0 insertions, 0 deletions