InferAddressSpaces assumes the pointee type of addrspacecast
is the same as the operand, which is not always true and causes
invalid IR.
This bug cause build failure in HCC.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D39432
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316957 91177308-0d34-0410-b5e6-96231b3b80d8
If particular target supports volatile memory access operations, we can
avoid AS casting to generic AS. Currently it's only enabled in NVPTX for
loads and stores that access global & shared AS.
Differential Revision: https://reviews.llvm.org/D39026
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@316495 91177308-0d34-0410-b5e6-96231b3b80d8
Many of these uses can get by with forward declarations. Hopefully this
speeds up compilation after adding a single intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312759 91177308-0d34-0410-b5e6-96231b3b80d8
InferAddressSpaces does not check address space in collectFlatAddressExpressions,
which causes values with non flat address space put into Postorder and causes
assertion in cloneValueWithNewAddressSpace.
This patch fixes assertion in OpenCL 2.0 conformance test generic_address_space
subtest for amdgcn target.
Differential Revision: https://reviews.llvm.org/D34991
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307349 91177308-0d34-0410-b5e6-96231b3b80d8
Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307292 91177308-0d34-0410-b5e6-96231b3b80d8
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304787 91177308-0d34-0410-b5e6-96231b3b80d8
These are pretty common when using local memory, and the 64-bit generic
addressing is much more expensive to compute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301711 91177308-0d34-0410-b5e6-96231b3b80d8
While looking at pure addressing expressions, it's possible
for the value to appear later in Postorder.
I haven't been able to come up with a testcase where this
exhibits an actual issue, but if you insert a dump before
the value map lookup, a few testcases crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301705 91177308-0d34-0410-b5e6-96231b3b80d8
Eliminates some more cases where some subset of the addressing
computation remains flat. Some cases with addrspacecasts
in nested constant expressions are still left behind however.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301704 91177308-0d34-0410-b5e6-96231b3b80d8
This is just asserting all the operations are handled in the
switch, which the unreachable already handles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301270 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes leaving intermediate flat addressing computations
where a GEP instruction's source is a constant expression.
Still leaves behind a trivial addrspacecast + gep pair that
instcombine is able to handle, which ideally could be folded
here directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301044 91177308-0d34-0410-b5e6-96231b3b80d8
