User Details
- User Since
- Oct 9 2015, 4:06 AM (415 w, 4 d)
Mon, Sep 4
Aug 14 2023
Indeed.
Yes, it did: the overload which has the return type as first argument.
Jul 11 2023
It would be nice to have a simple test case that shows the final assembly.
It's a tail call, isn't it? Does it have the same restriction as an LLVM IR tail call, that allocas in the caller cannot be accessed by the callee?
It seems this comes down to this question: Should the type properties be per type name or should they be per type?
Jun 29 2023
As shown by the many related revisions, this is clearly a good idea.
Jun 27 2023
Jun 22 2023
I think this larger context deserves a wider discussion
Rebase
Rebase
Main change is removal of sdata::Symbol in favor of plain StringRef
Jun 21 2023
Semi-related, I think we should start interpreting i1 argument values as SGPR masks (i1 inreg would be extended to sreg32)
Jun 20 2023
Move SchemaField into this patch
Move SchemaField out of this patch
Drop symbols-as-values for now
- Drop symbols-as-values for now
- LangRef clarifications
Drop symbols-as-values for now
I am very concerned about making this a global structure, rather than something bound to the context.
More generally, I'm not happy that this new concept is being introduced as part of the target type implementation. This doesn't really seem helpful for this specific use case (it makes the implementation substantially more complex rather than simpler). It may well make sense as part of some larger context, but I think this larger context deserves a wider discussion (probably on discourse) to clarify what the goals of this abstraction are and make sure we have a good design for it.
Could you please add a test where a target type is first used and later type info for it is provided? I'd like to make sure this is an error.
Missed a spot...
Rebase, mostly changes related to APInt bitwidth being preserved.
Rebase, layout type defaults to void
Add iN prefix to integers (and bool) in structured data values
Jun 19 2023
I tend to agree with Matt here. *Current* graphics APIs don't allow users to write code that uses dynamic allocas, but since the stack size can be set externally there's no fundamental reason why supporting them should be impossible.
Thanks, I like this much more :)
The proliferation of the ConvergenceControlUsage makes me a bit uncomfortable. It adds the overhead of an additional iteration over entire functions every time a function is inlined or perhaps the inlining is even attempted. And the only thing we get in exchange is a safety check against mixing controlled and uncontrolled convergent operations. Is it really worth it? I'd expect that in general, a compiler either always emits controlled or always emits uncontrolled operations, which means this isn't actually a scenario we need to worry about too much.
I think this is in pretty good shape. You may want to give it a bit more time in case more discussion shows up, but it's good for me.
I haven't looked at this in a while, sorry. I do plan to cycle back to it eventually, but right now my work scheduling is more stack-based than FIFO and this is fairly low down...
I'm not familiar with the code but the thrust of it makes sense. We should probably still try to CSE calls that are in the same basic block, though. Is that easy to do?
Jun 13 2023
Thank you all for the reviews. I've addressed the remaining small comments as part of the commit.
My 2 cents:
Jun 12 2023
Jun 6 2023
Jun 5 2023
Looks good to me apart from the comments.
Thanks, this looks pretty reasonable to me.
There could probably be a general section here to state that in the graphics calling conventions, inreg is used to denote arguments mapped to SGPRs, while other arguments are mapped to VGPRs.
Jun 1 2023
Address some review comments
Thank you for taking a look. I'm going to address the low-level issues you pointed out immediately.
May 31 2023
ping again after two weeks
May 30 2023
I think this is a reasonable compromise until we can land D147116, but maybe give a few more days for others to chime in.
This could be a top-level check in isSourceOfDivergence: if a source of divergence executes with a single lane, it de facto stops being a source of divergence.
May 23 2023
May 19 2023
Remove getStructType
Thanks for taking a look!
May 16 2023
Ah, my bad. I was working with local changes for so long that I hadn't noticed this got lost somehow. Sorry about that. I will follow-up with an adjustment to my later typeinfo diff.
There's nothing right now that would prevent this. Though we could default the layout type to something other than nullptr, if that is preferred. Maybe void?
May 15 2023
Okay, makes sense.
ping
This mostly LGTM, but it looks like some GlobalISel legalization is missing relative to SelectionDAG?
- explicitly list properties in LangRef
- add negative parser/assembler tests
- use tuple binding syntax
May 11 2023
Remove two TODOs that have been done.
Major update, adding IR printing, parsing and bitcode writing/reading of the type info.
May 8 2023
Absolutely do not globally reserve s[6:7] for such things. Low SGPRs are very often given special meaning in function signatures.
May 5 2023
- rebase on top of preparatory commits
- remove else after return
- add an explicit test for binary ops