From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: suggestion for Merging LLVM Date: Tue, 22 Nov 2011 15:32:55 -0500 Message-ID: <4ECC06F7.8040006@garzik.org> References: <4ECB38B1.8020803@garzik.org> <1321941674.1428.124.camel@jaguar> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-vx0-f174.google.com ([209.85.220.174]:40917 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758327Ab1KVUc6 (ORCPT ); Tue, 22 Nov 2011 15:32:58 -0500 Received: by vcbfk1 with SMTP id fk1so674322vcb.19 for ; Tue, 22 Nov 2011 12:32:57 -0800 (PST) In-Reply-To: <1321941674.1428.124.camel@jaguar> Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Pekka Enberg Cc: Christopher Li , Linus Torvalds , Linux-Sparse On 11/22/2011 01:01 AM, Pekka Enberg wrote: > On 11/21/2011 09:43 PM, Christopher Li wrote: >> FWIW I am sorta stuck; cannot figure out how to make 'phi' operation in >> LLVM work the way we need it to. That is a crucial hurdle needed for >> loops. LLVM fundamentally should be able to do it, but I'm not sure >> this works within the C API. I was thinking my next step would be to >> whine on the llvm list. >> >> A workaround is to resuscitate unssa() call, and all that entails. > > Did you check what kind of code http://llvm.org/demo/ generates for your > test case? I've noticed that LLVM is really picky sometime in what it > accepts as input. IIRC last time I looked at loops, there were some > significant differences in the asm we generate. The disassembler output is certainly sane and understandable. Here's an example test case: extern int bar(int x); int foo (int x) { int y = 0; while (y < 1000) { y += bar(x); } return y; } The PHI operation in SSA being a union of control flows, we need to reference all input pseudos ... including pseudos generated by operations further down the in the code (i.e. pseudos not yet generated). A classic forward reference is needed, and I cannot figure out how to do that in the LLVM C API, even though the forward reference is plain and obvious in the LLVM text disassembly. My next step was going to trace through the front end to see how it generates forward refs, or be lazy and brain dump on an llvm mailing list somewhere. Problems like this were the original motivation for my earlier LLVM backend to generate ASCII text. I could work around this problem with an ugly string-based hack, if not using the C API... ;) Jeff