- User Since
- Jul 1 2015, 10:19 AM (207 w, 6 d)
Fri, Jun 21
Thu, Jun 20
Unfortunately, I've never worked in the IntrinsicEmitter so I can't really comment on the correctness of the patch. I will make some inline comments on non-correctness things.
This is the subset of D58736 covering changes to TTI and related classes. It does not introduce any new functionality, only reorganizes things a bit to move implementations into subtargets in preparation for defining system models for targets.
I just posted D63614, the subset of this patch covering only the changes to TTI and related classes.
Fri, Jun 14
Updated to address comments.
Tue, May 28
May 26 2019
May 24 2019
Oops, needs a testcase. Will add.
May 13 2019
May 9 2019
What's the status of this? It seems like discussion has died down a bit. I think Graham's idea to change from <scalable 2 x float> to <vscale x 2 x float> will make the IR more readable/understandable but it's not a show-stopper for me.
May 8 2019
May 7 2019
Added a test for catchswitch and fixed a bug with falling off the end of a basic block.
May 1 2019
Updated to account for isEHPad including catchswitch. I'm not very happy with the hacky use of FoundCatchSwitch but could not think of a way to do this that keeps things relatively clear/readable and doesn't put the for loop into a deeper nesting level or completely reformat the function.
Apr 30 2019
Bail out of the loop that found an existing neg if there is a catchswitch
and just create a new neg instead.
Updated to use isEHPad.
Apr 29 2019
Rebased on latest master and fixed test name.
Apr 24 2019
Apr 22 2019
Apr 17 2019
We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?
Apr 3 2019
Mar 20 2019
Mar 14 2019
Mar 8 2019
This all LGTM.
Mar 7 2019
I know this isn't ready for merge, but since the mailing list discussion has died down it seems like maybe we should move the discussion here. If so, it would be helpful to have comments on all the routines explaining what they do and how they differ from the existing routines, in order to aid discussion.
Mar 6 2019
Feb 28 2019
Cool,. I've wanted this for a while. LGTM.
Feb 27 2019
A larger design question I have about this is the proper place to put software prefetching configuration. Right now it lives at the memory model level, in that a memory model specifies a cache heirachy along with a software prefetch configuration. I wonder if we should allow for software prefetching configuration for each cache level, as targets might want different policies depending on which cache level they are prefetching into. I don't think we have any examples of that in the codebase today but I can imagine cases where targets might want it.
Feb 22 2019
I believe https://reviews.llvm.org/D56266 is working for me.
+1. Is there any reason not to use "%4" in the definition?
Feb 11 2019
Feb 7 2019
Feb 4 2019
Jan 31 2019
Jan 29 2019
Note important considerations with respect to upstream merges after zipping.
Added --source-kind=split to the migrate-downstream-fork.py example.
Jan 28 2019
Updated for new and improved zipping tool.
Jan 10 2019
Updated with blessed monorepo URL.
Fixed more typos.
Fixed various typos.
Do a lot of people use the old monorepo for development? We don't so I haven't developed any process for migrating from that. I'll leave that to someone else to add.
I could certainly put these instructions in a separate document, but where should it go? This is a one-time operation and so it doesn't make sense to put it in with the regular LLVM docs. It's not a proposal, per se, so I don't think it belongs in docs/Proposals other than as an addition to a related proposal, which is this document.
Noted that when zipping, and non-LLVM repositories added as submodules need to be imported into the monorepo.
I created some instructions in D56550 which should cover the most common cases.
Jan 9 2019
As @bogner mentioned, the last section (Multirepo to Monorepo, With Merges) is almost certainly the most common downstream situation. I may write up some recipes under this header and move it to a more prominent position in a separate patch. The discussion of the other situations is orthogonal to the kinds of things I found I needed to do downstream.
What's the status of this? Since the monorepo prototype seems very likely to be blessed soon, I was thinking of writing up some recipes for common downstream migrations. This document would seem to be the right place to put them but it seems from all the comments that this is very much in flux.
Jan 7 2019
Better handle clang-tools-extra too.
Updated to use CACHE_STRING as suggested.
Jan 6 2019
This also looks fine to me but I'm in the same boat as Jonas when it comes to (non-)knowledge of GlobalISel.
It's still just an intrinsic so i do not see how transformations that only look at Instruction and don't dig deeper could break the EVL intrinsic call.
Jan 4 2019
No, I haven't implemented `frameaddress` or done any GISel work at all. From our ML conversation, I was under the impression that the tests didn't need `-fno-experimental-isel`` anymore.
Jan 2 2019
Dec 21 2018
What are the semantics for a call that doesn't have a passthrough attribute? For disabled lanes what's the expected output value? I hope it's undef.
Sorry, I'm joining this conversation late.
Nov 13 2018
Oops, I didn't realize this hadn't been formally accepted yet. Still learning the Phab process. Let me know if you want it reverted for a formal accept.