This patch outputs all the list of instructions in BlockStmts.
Details
Diff Detail
Event Timeline
@nandini12396: Thanks for the patch! Other than the minor nitpicks that I have, LGTM :)
Nitpick: I was hoping the patch could be submitted with context. By context, I mean the context not available that is written in the Phabricator UI. For a patch "with context", consider this one, where you have the: ▲ Show 20 Lines • Show All 57 Lines • ▼ Show 20 Line(s) available.
Generating Context:
Context using git:
If you are uploading patches directly using git, the way to generate context is by using git -U<number of lines> or git --unified=<number of lines>. I don't use this, but I believe @Meinersbur mentioned using that, and that he uses 99999 or some absurdly large number like that to get all the context.
TL,DR: $ git diff <branch> <other branch> -U999999
Context using arcanist:
I personally use arc, which is a command line tool for Phabricator. It handles a lot of the stuff for you, and I find the experience much nicer. There's some documentation on how to use it for LLVM here. arc automatically generates the context information, so it's somewhat easier to use.
Submitting a new patch:
$ arc diff --reviewers=efriedma,jdoerfert,Meinersbur,gareevroman,sebpop,zinob,huihuiz,pollydev,grosser,philip.pfaffe,etherzhhb master --nolint --nounit
- the --reviewers specifies who is reviewing the code. You can add / remove people from that list.
- --nolint --nounit asks arc to ignore running lint and unit tests, because Phabricator isn't setup to run these for LLVM is my understanding of this (I could be wrong, could someone confirm this?)
- master is the branch against which you want to generate the diff. this can be changed to another branch if you want to.
Updating a patch:
$ arc diff --update D32639 master --nolint --nounit
- D32639 is the patch number. You can change this to D33163 for example for this case.
- Once again, master is the branch against which you want to diff.
Setting up arcanist:
If I recall correctly, you will need to setup git-svn to be able to use arcanist. There's not much to do, except to add these lines into the .git/config file inside your polly repository:
... [svn-remote "svn"] url = https://grosser@llvm.org/svn/llvm-project/polly/trunk fetch = :refs/remotes/origin/master ...
- There are also general instructions for git-svn [documented here: LINK](http://llvm.org/docs/GettingStarted.html#developers-work-with-git-svn) should work.
- Setting up arcanist is somewhat annoying, but I believe it simplifies the experience of actually submitting a patch IMO.
include/polly/ScopInfo.h | ||
---|---|---|
1117 | Would it be possible to have the std::vector<Instructor*> BBToInst be moved? As in, can the constructor be changed to: new-constructor ScopStmt(Scop &parent, BasicBlock &bb, Loop *SurroundingLoop, std::vector<Instruction *> &&BBToInst); | |
1225 | Are there any uses of BBToInst other than to print the instructions? If not, can we change it to: std::vector<const Instruction*> BBToInst; If there are other uses where we mutate the Instruction, then this is perfectly fine. | |
1482 | Could you please add a comment to printInstructions explaining what it does? |
I cannot apply the patch. Can you rebase to the latest trunk?
include/polly/ScopInfo.h | ||
---|---|---|
1225 | Could you reconsider the name? BBToInst indicates a kind of map, and there are no BasicBlocks involed. Please don't add const.
| |
lib/Analysis/ScopBuilder.cpp | ||
427 | You can move this declaration into the else branch, avoiding it being initialized when not used. |
@bollu : Thank you very much for the detailed explanation. :) I will submit a patch with context from next time.
@Meinersbur ; I have rebased, changed the name of the list and moved the declaration to else.
@grosser : Sorry for delay. I will quickly update the diff after printing instructions per statement.
Hi Nandini,
thanks for the update. Find below some more comments.
I also saw that with your patch we currently get 118 unexpected failures when running 'make check-polly'. They seem to be caused because we print instructions now always. I think this might be too verbose in general. Can we make instruction printing optional and hide it behind a flag?
include/polly/ScopInfo.h | ||
---|---|---|
1145 | In LLVM Variables start with uppercase letters. Also, I would just call it "Instructions" | |
1253 | Please use uppercase. | |
1540 | Add an empty line between print() and the comment that follows it. | |
2030 | Uppercase, variable name. | |
lib/Analysis/ScopBuilder.cpp | ||
635 | Uppercase, variable name. | |
lib/Analysis/ScopInfo.cpp | ||
1654 | Uppercase variable name. | |
4663 | Uppercase variable name. | |
test/ScopInfo/statement.ll | ||
15 | These CHECK lines do not seem correct. If I run po -polly-process-unprofitable -polly-remarks-minimal -polly-use-llvm-names -polly-scops -analyze < /home/grosser/Projects/polly/git/tools/polly/test/ScopInfo/statement.ll I get: Statements { Stmt_Stmt Domain := { Stmt_Stmt[i0] : 0 <= i0 <= 1023 }; Schedule := { Stmt_Stmt[i0] -> [i0] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 0] { Stmt_Stmt[i0] -> MemRef_A[i0] }; MustWriteAccess := [Reduction Type: NONE] [Scalar: 0] { Stmt_Stmt[i0] -> MemRef_B[i0] }; Instructions { %idxprom = sext i32 %i.0 to i64 %arrayidx = getelementptr inbounds i32, i32* %A, i64 %idxprom store i32 %i.0, i32* %arrayidx, align 4 %idxprom1 = sext i32 %i.0 to i64 %arrayidx2 = getelementptr inbounds i32, i32* %B, i64 %idxprom1 store i32 %i.0, i32* %arrayidx2, align 4 br label %for.inc } } These four "CHECK" lines do not make sense: ; CHECK-NEXT: %i.0 = phi i32 [ 0, %entry ], [ %add, %for.inc ] ; CHECK-NEXT: %cmp = icmp slt i32 %i.0, 1024 ; CHECK-NEXT: br i1 %cmp, label %for.body, label %for.end ; CHECK-NEXT: br label %Stmt Also, the indentation seems off. |
Would it be possible to have the std::vector<Instructor*> BBToInst be moved? As in, can the constructor be changed to: