On 11/21/2011 09:43 PM, Christopher Li wrote: > > I already tag the sparse 0.4.4 release in git. Just waiting > > for getting the release directory setup on kernel.org and it > > is ready to go. > > > > Now I am looking at your LLVM repository and the llvm patches. > > I don't have a good sense for the later patch without looking at the > > earlier changes. > > > > I haven't done big repository merge before, this is the first one. > > So I am looking for suggestion what is the best practice here. > > > > Do we care about clean up the history and import the changes > > step by step as patches or just a plain git merge of the LLVM > > repository? On Tue, 2011-11-22 at 00:52 -0500, Jeff Garzik wrote: > I don't see any reason to import step-by-step as patches. > > Either merge it as a single "add incomplete LLVM backend" commit, > dropping all pre-upstream history, or git merge. Agreed. I'd actually prefer that we keep the full history for one simple reason: the commit changelogs. They provide valuable information on why we've implemented the things the way we have. > 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. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
