https://github.com/krzysz00 commented:
I think the RFC's at consensus and that things are in a decent state.
One comment I have is that the documentation mentions vectors of pointers and I
don't see any tests for that.
But that minor issue aside, I'd lay ... one last call for comments before t
krzysz00 wrote:
Ping
https://github.com/llvm/llvm-project/pull/140849
___
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.
https://github.com/llvm/llvm-project/pull/142015
___
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 created
https://github.com/llvm/llvm-project/pull/140849
Now that `Property` is a `PropConstraint`, hook it up to the same
constraint-uniquing machinery that other types of constraints use. This will
primarily save on code size for types, like enums, that have inher
krzysz00 wrote:
PR stack: Lives on top of #140848
https://github.com/llvm/llvm-project/pull/140849
___
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/
@@ -4904,13 +4907,43 @@ class PtrToIntInst : public CastInst {
// Methods for support type inquiry through isa, cast, and dyn_cast:
static bool classof(const Instruction *I) {
-return I->getOpcode() == PtrToInt;
+return I->getOpcode() == PtrToInt || I->getOpcode()
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
@@ -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
@@ -1952,6 +1953,22 @@ PtrParts SplitPtrStructs::visitPtrToIntInst(PtrToIntInst
&PI) {
return {nullptr, nullptr};
}
+PtrParts SplitPtrStructs::visitPtrToAddrInst(PtrToAddrInst &PA) {
+ Value *Ptr = PA.getPointerOperand();
+ if (!isSplitFatPtr(Ptr->getType()))
+return
https://github.com/krzysz00 approved this pull request.
One tiny nit, lgtm otherwise
https://github.com/llvm/llvm-project/pull/139413
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/139413
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
krzysz00 wrote:
Ping
https://github.com/llvm/llvm-project/pull/138930
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
krzysz00 wrote:
PRs this depends on:
* #138929
https://github.com/llvm/llvm-project/pull/138930
___
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 created
https://github.com/llvm/llvm-project/pull/138930
This PR updates the FoldMemRefAliasOps to use `affine.linearize_index` and
`affine.delinearize_index` to perform the index computations needed to fold a
`memref.expand_shape` or `memref.collapse_shape` into it
krzysz00 wrote:
Also, re the C quote (having now re-read your comment more thoroughly), I'm
comfortable saying that, for the purposes of C's pointer operations, `A` and
`B` are *not* in "the same address space" in the buffer fat pointer context.
They're distinct but potentially overlappin
krzysz00 wrote:
> I think we just have to pretend that virtual addresses or segment-relative
> addresses are the only thing that matters.
This is why I've been advocating for the index-based definition of ptrtoaddr.
So there's no need to do this 48-bit thing on the assumption that the base of
krzysz00 wrote:
So p9 is quite weird. It's used, IIRC, by,
https://github.com/GPUOpen-Drivers/llpc internally to represent "structured"
pointers, and so its interpretation is `{p8 rsrc, i32 index, i32 offset}` .
This does still have a 48-bit effective address by way of a thoroughly weird
ptrt
krzysz00 wrote:
You'll want to get p9 as well, and _maybe_ p8 - though p8 is a very weird kind
of "pointer" that's just the resource and can't - for example - be GEP'd
https://github.com/llvm/llvm-project/pull/137418
___
llvm-branch-commits mailing li
https://github.com/krzysz00 approved this pull request.
Seems reasonable to me
https://github.com/llvm/llvm-project/pull/134685
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm
@@ -66,20 +67,34 @@ static void emitEnumClass(const Record &enumDef, StringRef
enumName,
os << "};\n\n";
}
-static void emitParserPrinter(const EnumAttr &enumAttr, StringRef qualName,
+static void emitParserPrinter(const EnumInfo &enumInfo, StringRef qualName,
https://github.com/krzysz00 updated
https://github.com/llvm/llvm-project/pull/132349
>From b7e84740dbe3795a87deb0e7b7fe5d92d181f7b1 Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Thu, 20 Mar 2025 23:08:31 -0700
Subject: [PATCH] [mlir] Improve EnumProp, making it take an EnumInfo
This
@@ -128,8 +143,95 @@ namespace llvm {
inline ::llvm::raw_ostream &operator<<(::llvm::raw_ostream &p, {0} value) {{
auto valueStr = stringifyEnum(value);
)";
- os << formatv(parsedAndPrinterStart, qualName, cppNamespace,
-enumAttr.getSummary());
+
+ const cha
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/132148
___
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 created
https://github.com/llvm/llvm-project/pull/132349
This commit improves the `EnumProp` class, causing it to wrap around an
`EnumInfo` just like` EnumAttr` does. This EnumProp also has logic for
converting to/from an integer attribute and for being read and wri
@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/105735
___
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 commented:
I like the external state thing and think this is a good clarification /
breakdown overall, just one comment
https://github.com/llvm/llvm-project/pull/105735
___
llvm-branch-commits mailing list
llvm-branch-commi
@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
https://github.com/krzysz00 updated
https://github.com/llvm/llvm-project/pull/124876
>From 088e3e73785e2a8880f0e0cb063d932cf0caab2b Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Tue, 28 Jan 2025 20:25:38 -0800
Subject: [PATCH 1/2] [mlir][ODS] Switch declarative rewrite rules to
prope
https://github.com/krzysz00 updated
https://github.com/llvm/llvm-project/pull/124713
>From e7ae9837e983d62c4b6bff04e3b193915c80d8af Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Sat, 18 Jan 2025 00:01:35 -0800
Subject: [PATCH 1/3] [mlir][ODS] Add a collective builder that takes the
P
https://github.com/krzysz00 updated
https://github.com/llvm/llvm-project/pull/124876
>From 4fcff8c53af4055b6d92c5399e9f88a7fea18677 Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Tue, 28 Jan 2025 20:25:38 -0800
Subject: [PATCH 1/2] [mlir][ODS] Switch declarative rewrite rules to
prope
https://github.com/krzysz00 approved this pull request.
Per further discussion, given the broader context of these changes, this is
fine assuming @arsenm's comments about the documentation are addressed.
https://github.com/llvm/llvm-project/pull/125836
__
krzysz00 wrote:
I'll try and remember to go to that
https://github.com/llvm/llvm-project/pull/125836
___
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 updated
https://github.com/llvm/llvm-project/pull/124713
>From 5b7c91328d935f203acd571488f16f709200cc1e Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Sat, 18 Jan 2025 00:01:35 -0800
Subject: [PATCH 1/3] [mlir][ODS] Add a collective builder that takes the
P
https://github.com/krzysz00 updated
https://github.com/llvm/llvm-project/pull/124876
>From 5dc001f21e663d3a2e9dfdaa46b29a8731d21af9 Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Tue, 28 Jan 2025 20:25:38 -0800
Subject: [PATCH 1/2] [mlir][ODS] Switch declarative rewrite rules to
prope
@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
krzysz00 wrote:
Re OpenCL and the linked test: we don't have an integration test for OpenCL's
lowering because we don't have a way to execute it
https://github.com/llvm/llvm-project/pull/121067
___
llvm-branch-commits mailing list
llvm-branch-commits@
@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
@@ -650,48 +650,127 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a wor
@@ -649,48 +649,95 @@ literal types are uniqued in recent versions of LLVM.
.. _nointptrtype:
-Non-Integral Pointer Type
--
+Non-Integral and Unstable Pointer Types
+---
-Note: non-integral pointer types are a work
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/105735
___
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 commented:
Ok, so, first blob of thoughts - overall, this looks right.
https://github.com/llvm/llvm-project/pull/105735
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/krzysz00 approved this pull request.
1. Approved
2. Wrt OpenCL ... I hope legalization didn't get broken, but in the OpenCL
flow, pryntf should lower to ... `printf()`, which the compiler will handle. Or
at least that's my recollection of how that goes from staring at the AMD
krzysz00 wrote:
So as to note upcoming plans:
- EnumProp probably wants to move to `EnumAttr` and grow a real predicate.
- `IndexProp` and `APIntProp` (name subject to debate) should exist
- Once the infrastructure feels like it's in a solid shape, I intend to go on a
rampage through the upstrea
https://github.com/krzysz00 created
https://github.com/llvm/llvm-project/pull/120368
Since the property system isn't currently in heavy use, it's probably the right
time to fix a choice I made when expanding ODS property support.
Specifically, most of the property subclasses, like OptionalProp
@@ -63,6 +65,12 @@ class Property {
return convertFromAttribute($_storage, $_attr, $_diag);
}];
+ // The verification predicate for this property. Defaults to And<[]>,
+ // which is trivially true, since properties are always their expected type.
+ // Within the predi
https://github.com/krzysz00 created
https://github.com/llvm/llvm-project/pull/120176
Give the properties from tablegen a `predicate` field that holds the predicate
that the property needs to satisfy, if one exists, and hook that field up to
verifier generation.
>From e8b571f614adbc68ad551798c
@@ -209,7 +209,12 @@ struct GPULaneIdOpToNVVM :
ConvertOpToLLVMPattern {
ConversionPatternRewriter &rewriter) const override {
auto loc = op->getLoc();
MLIRContext *context = rewriter.getContext();
-Value newOp = rewriter.create(loc, rewriter.getI
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/107659
___
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 updated
https://github.com/llvm/llvm-project/pull/107659
>From c7d3804afe9a7e6325f6af230f060c19aceca09b Mon Sep 17 00:00:00 2001
From: Krzysztof Drewniak
Date: Fri, 6 Sep 2024 23:45:52 +
Subject: [PATCH 1/3] [mlir][GPU] Plumb range information through the NVVM
l
@@ -699,9 +699,21 @@ gpu.module @test_module_32 {
}
gpu.module @test_module_33 {
-// CHECK-LABEL: func @kernel_with_block_size()
-// CHECK: attributes {gpu.kernel, gpu.known_block_size = array, nvvm.kernel, nvvm.maxntid = array}
- gpu.func @kernel_with_block_size() kernel att
@@ -209,7 +209,12 @@ struct GPULaneIdOpToNVVM :
ConvertOpToLLVMPattern {
ConversionPatternRewriter &rewriter) const override {
auto loc = op->getLoc();
MLIRContext *context = rewriter.getContext();
-Value newOp = rewriter.create(loc, rewriter.getI
@@ -1784,53 +1799,53 @@ def NVVM_CpAsyncBulkWaitGroupOp :
NVVM_Op<"cp.async.bulk.wait_group">,
}];
}
-def NVVM_CpAsyncBulkTensorGlobalToSharedClusterOp :
- NVVM_Op<"cp.async.bulk.tensor.shared.cluster.global",
- [DeclareOpInterfaceMethods,
+def NVVM_CpAsyncBulkTensorGl
https://github.com/krzysz00 ready_for_review
https://github.com/llvm/llvm-project/pull/107659
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
krzysz00 wrote:
> [!WARNING]
> This pull request is not mergeable via GitHub because a downstack PR is
> open. Once all requirements are satisfied, merge this PR as a stack href="https://app.graphite.dev/github/pr/llvm/llvm-project/107659?utm_source=stack-comment-downstack-mergeability-warning"
https://github.com/krzysz00 created
https://github.com/llvm/llvm-project/pull/107659
Update the GPU to NVVM lowerings to correctly propagate range
information on IDs and dimension queries, etiher from
known_{block,grid}_size attributes or from `upperBound` annotations on
the operations themselve
@@ -1582,33 +1603,33 @@ let OtherPredicates = [isGFX12Plus] in {
}
}
-let OtherPredicates = [isGFX10Plus] in {
+let SubtargetPredicate = HasAtomicFMinFMaxF32GlobalInsts, OtherPredicates =
[HasFlatGlobalInsts] in {
defm : GlobalFLATAtomicPats <"GLOBAL_ATOMIC_FMIN", "atomic_
https://github.com/krzysz00 edited
https://github.com/llvm/llvm-project/pull/95592
___
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 commented:
I'm not seeing anything obviously wrong here, but I don't know if I'm the right
person to approve this in
https://github.com/llvm/llvm-project/pull/95592
___
llvm-branch-commits mailing list
llvm-branch-commits@l
https://github.com/krzysz00 approved this pull request.
https://github.com/llvm/llvm-project/pull/95593
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
krzysz00 wrote:
On the other hand, it's a lot easier to handle ugly types down in instruction
selection, where you get to play much more fast and loose with types.
And there are buffer uses that don't fit into the fat pointer use use case
where we'd still want them to work.
For example, both `
krzysz00 wrote:
Yeah, makes sense.
... what prevents a match-bitwidth operator from existing?
Context from where I'm standing is that you should be able to
`raw.buffer.load/store` any (non-aggregate, let's say, since that could be
better handled in `addrspace(7)` handling) type you could `loa
krzysz00 wrote:
So, general question on this patch series:
Wouldn't it be more reasonable to, instead of having separate handling for all
the possible register types, always do loads as `i8`, `i16`, `i32` `<2 x i32>`,
`<3 x i32>, or `<4 x i32>` and then `bitcast`/`merge_values`/... the results
68 matches
Mail list logo
