https://github.com/arichardson updated
https://github.com/llvm/llvm-project/pull/139419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/arichardson updated
https://github.com/llvm/llvm-project/pull/139419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/krzysz00 approved this pull request.
Thanks for the ping, this looks good to me
https://github.com/llvm/llvm-project/pull/139419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
arichardson wrote:
Is there anything else that needs to be changed on this PR?
https://github.com/llvm/llvm-project/pull/139419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm
krzysz00 wrote:
> Technically true, but why not just call it 64?
Because we really don't want to be doing 64-bit arithmetic on a buffer resource
- that'll spill over to the stride bits
That is, while `ptr addrspace(1)` (or x86's pointers) have 48 "real" address
bits that are stored as 64 bits
@@ -7970,17 +7970,26 @@ void SelectionDAGBuilder::visitIntrinsicCall(const
CallInst &I,
// On arm64_32, pointers are 32 bits when stored in memory, but
// zero-extended to 64 bits when in registers. Thus the mask is 32 bits to
-// match the index type, but the po
arsenm wrote:
> Of the 128-bits of buffer descriptor only 48 bits are address bits,
Technically true, but why not just call it 64?
https://github.com/llvm/llvm-project/pull/139419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
@@ -5773,7 +5773,7 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL,
StringRef TT) {
if (!DL.contains("-p7") && !DL.starts_with("p7"))
Res.append("-p7:160:256:256:32");
if (!DL.contains("-p8") && !DL.starts_with("p8"))
- Res.append("-p8:128:128");
+
@@ -5773,7 +5773,7 @@ std::string llvm::UpgradeDataLayoutString(StringRef DL,
StringRef TT) {
if (!DL.contains("-p7") && !DL.starts_with("p7"))
Res.append("-p7:160:256:256:32");
if (!DL.contains("-p8") && !DL.starts_with("p8"))
- Res.append("-p8:128:128");
+
https://github.com/krzysz00 commented:
Minor note re the autoupgrade, overall this change makes sense
(and it does mean that, if we can get GEP's "wrapping add on the index bits"
behavior working, ptr addrspace(8)` becomes *technically* GEPable, though with
the note of "be real hecking careful
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/139419
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -145,79 +145,79 @@ define amdgpu_ps ptr addrspace(7)
@s_ptrmask_buffer_fat_ptr_i32_neg8(ptr addrspa
ret ptr addrspace(7) %masked
}
-define ptr addrspace(8) @v_ptrmask_buffer_resource_variable_i128(ptr
addrspace(8) %ptr, i128 %mask) {
-; GCN-LABEL: v_ptrmask_buffer_resou
llvmbot wrote:
@llvm/pr-subscribers-mlir-llvm
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic conclu
@@ -145,79 +145,79 @@ define amdgpu_ps ptr addrspace(7)
@s_ptrmask_buffer_fat_ptr_i32_neg8(ptr addrspa
ret ptr addrspace(7) %masked
}
-define ptr addrspace(8) @v_ptrmask_buffer_resource_variable_i128(ptr
addrspace(8) %ptr, i128 %mask) {
-; GCN-LABEL: v_ptrmask_buffer_resou
@@ -7970,17 +7970,26 @@ void SelectionDAGBuilder::visitIntrinsicCall(const
CallInst &I,
// On arm64_32, pointers are 32 bits when stored in memory, but
// zero-extended to 64 bits when in registers. Thus the mask is 32 bits to
-// match the index type, but the po
llvmbot wrote:
@llvm/pr-subscribers-llvm-analysis
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic co
llvmbot wrote:
@llvm/pr-subscribers-flang-openmp
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic con
llvmbot wrote:
@llvm/pr-subscribers-llvm-globalisel
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-llvm-transforms
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-pt
llvmbot wrote:
@llvm/pr-subscribers-backend-amdgpu
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic c
llvmbot wrote:
@llvm/pr-subscribers-llvm-ir
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic conclusi
llvmbot wrote:
@llvm/pr-subscribers-llvm-selectiondag
Author: Alexander Richardson (arichardson)
Changes
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logi
https://github.com/arichardson created
https://github.com/llvm/llvm-project/pull/139419
Of the 128-bits of buffer descriptor only 48 bits are address bits, so
following the discussion on
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54,
the logic conclusion is to set
23 matches
Mail list logo