| Message ID | CA+55aFxGwAXRWVcv_Qx6C4B_PKqzVVbc8O_znwUt_D6g1iDJvQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 08/27/2011 11:53 AM, Linus Torvalds wrote: > On Sat, Aug 27, 2011 at 8:37 AM, Jeff Garzik<jeff@garzik.org> wrote: >> >> On our point of view, we probably prefer to simply turn off as many >> transformations as possible. They just waste time, when an optimizing LLVM >> backend is going to perform the same transformations anyway. > > I disagree - mainly because I don't think we're interested in the back > end, are we? > > If we were doing LLVM hacking, then I'd agree. But as it is, we're > supposed to improve sparse, not LLVM, so we should make sure that the > _sparse_ output makes sense, and LLVM is just a code generator, no? No idea Pekka's interest... In general, my own decade-long goal has been to be able to play with a kernel compiler other than gcc. That's why I wrote compile-i386 so long ago, that's why the kernel got a bunch of LLVM-related bug fixes and C cleanups, that's why I wrote the original sparse LLVM backend[1], and why I'm working on Pekka's now. So I'm definitely more interested in the backend side of things, and tend to see simplifications and optimizations performed on the linearized form as wasted work. sparse makes a great C front-end to a compiler. Obviously that's not the only PoV or use case of sparse, and is arguably a crazy, unattainable goal in general... :) Jeff [1] https://patchwork.kernel.org/patch/19923/ -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Aug 27, 2011 at 11:03 PM, Jeff Garzik <jeff@garzik.org> wrote: >> I disagree - mainly because I don't think we're interested in the back >> end, are we? >> >> If we were doing LLVM hacking, then I'd agree. But as it is, we're >> supposed to improve sparse, not LLVM, so we should make sure that the >> _sparse_ output makes sense, and LLVM is just a code generator, no? > > No idea Pekka's interest... > > In general, my own decade-long goal has been to be able to play with a > kernel compiler other than gcc. [snip] I'm also interested in hopefully being able to eventually compile the kernel with sparse. I'm not that interested in LLVM and really only picked it because it seems to be simplest solution for now. I do agree with Linus that we should improve sparse rather than rely on LLVM for everything. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cse.c | 7 ------- linearize.c | 14 +++++--------- 2 files changed, 5 insertions(+), 16 deletions(-) diff --git a/cse.c b/cse.c index 2a1574531993..2aabb65785f0 100644 --- a/cse.c +++ b/cse.c @@ -317,13 +317,6 @@ static struct instruction * try_to_cse(struct entrypoint *ep, struct instruction b2 = i2->bb; /* - * PHI-nodes do not care where they are - the only thing that matters - * are the PHI _sources_. - */ - if (i1->opcode == OP_PHI) - return cse_one_instruction(i1, i2); - - /* * Currently we only handle the uninteresting degenerate case where * the CSE is inside one basic-block. */ diff --git a/linearize.c b/linearize.c index f2034ce93572..06128ed5b5ee 100644 --- a/linearize.c +++ b/linearize.c @@ -2060,16 +2060,10 @@ pseudo_t linearize_statement(struct entrypoint *ep, struct statement *stmt) concat_symbol_list(stmt->iterator_syms, &ep->syms); linearize_statement(ep, pre_statement); - loop_body = loop_top = alloc_basic_block(ep, stmt->pos); + loop_body = alloc_basic_block(ep, stmt->pos); loop_continue = alloc_basic_block(ep, stmt->pos); loop_end = alloc_basic_block(ep, stmt->pos); - /* An empty post-condition means that it's the same as the pre-condition */ - if (!post_condition) { - loop_top = alloc_basic_block(ep, stmt->pos); - set_activeblock(ep, loop_top); - } - if (pre_condition) linearize_cond_branch(ep, pre_condition, loop_body, loop_end); @@ -2082,10 +2076,12 @@ pseudo_t linearize_statement(struct entrypoint *ep, struct statement *stmt) set_activeblock(ep, loop_continue); linearize_statement(ep, post_statement); + + /* No post-condition means that it's the same as the pre-condition */ if (!post_condition) - add_goto(ep, loop_top); + linearize_cond_branch(ep, pre_condition, loop_body, loop_end); else - linearize_cond_branch(ep, post_condition, loop_top, loop_end); + linearize_cond_branch(ep, post_condition, loop_body, loop_end); set_activeblock(ep, loop_end); break; }