similar to: LLVM bc converter from LLVM 3.9 to LLVM 3.1

> > I also have a look at the code, looks like it directly parse the bitcode > and build in memory representation in a different LLVM version than the > bitcode. Is this correct? According to your description, I guess the BitCodeWriter should be the one > to do the bitcode version downgrade, right? I think so. I don't know much about it and don't want to give you

Hi Steve, Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the oldest version of bitcode that the TOT bitcode reader supports? Also, why do you generate bitcode instead of the textural representation, i.e. the "ll" file, for older version of LLVM? I guess generating "ll" code is simpler. Another approach I am

> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Hongbin, > > On Tue, Aug 2, 2016 at 8:26 PM, Hongbin Zheng <etherzhhb at gmail.com <mailto:etherzhhb at gmail.com>> wrote: > Hi Steve, > > Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the

Thanks Steve and Mehdi for the explanation. Steve, I am a little be confused by looking at the code in https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp. Looks like the BitcodeReader do some translation while reading the bitcode. If LLVM ToT can read the bitcode of LLVM 3.0, while can't we just use the bitcode reader in LLVM

> On Aug 2, 2016, at 8:49 PM, Stephen Hines <srhines at google.com> wrote: > > > > On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>

> > but doesn't emit optnone and nounwind attributes > s/nounwind/noinline On Mon, Jan 28, 2019 at 11:35 AM Jakub (Kuba) Kuderski < kubakuderski at gmail.com> wrote: > As far as I understand, gllvm doesn't run LTO pipeline or any cross-module > optimization, and the optimization level provided is only used to compile > each Translation Unit separately. > If you

This works great. > You can also try using the gllvm wrapper: https://github.com/SRI-CSL/gllvm ; it's quite reliable and easy to use in my experience. Just to be sure. Only one version of bc file will be generated that corresponds to the compiler options provide at configure? The original approach using ld.gold will provide several .bc files that correspond to different stages of the

Hello, I was wondering whether or not some behaviour that I am seeing is expected behaviour and that it has been designed like this, or not. A dominator relation is given by "if A dominates B", then all paths to B go through A. For example, take the CFG below (which is a directed graph (couldn’t make the arrow heads but ok.): A / \ B C \ / D | E We can construct

Hi Jakub! On Mon, 17 Jun 2019 at 17:01, Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > Hi Kristóf, > > >> 1. I read the article IDFCalculator is based on[1], but I found no >> references to IDFCalculator::setLiveInBlocks, and the file header seems to >> confirm that it's an implementation specific thing. Could I get away >> restricting the

Hi Kuba, Thanks for your clarification on the project in the previous letter. I have submitted a proposal draft at the GSoC website, the draft has been shared with the LLVM organization. I will appreciate it if you can give me some advice on the proposal. This draft can be viewed by the organization. (If you do not have access, please mail me, and I will give you the link.) I am looking forward

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

This is getting a bit off-topic, but since Renato brought up RenderScript, I wonder if the Android libbcc interface wouldn't be a cleaner way to approach this problem. It provides more or less the same functionality as MCJIT and in almost the same way. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Renato Golin Sent: Tuesday, November 05,

Hi Kuba, Thanks for your feedback. I have made some improvements on the proposal according to your feedback and clarify something on the time availability. I left comments on the questions you asked in the doc. Please check it out. Thanks, Chijun 2018-03-22 10:37 GMT+08:00 Jakub (Kuba) Kuderski <kubakuderski at gmail.com>: > Hi Chijun, > > I left you my feedback in the doc (+

Hi Chijun, I left you my feedback in the doc (+ some nitpicks). Overall, it looks very solid and shows you understand the problem well and know what to expect. Your proposed timeline is reasonable and I don't see any major things to improve there. Don't hesitate to reach out if you have any questions related to my comments (either here or in the document). Thanks, Kuba On Wed, Mar 21,

I did a sanity check and run some of the bitcode I complied with gllvm and it seems to work fine under lli. The only issues is to make sure you load all the (external) libraries the bitcode needs. I highly suggest you run a debug version of lli under a debugger and see what exactly happens. On Mon, Jan 28, 2019 at 12:45 PM Peng Yu <pengyu.ut at gmail.com> wrote: > It seems that it does

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to

Hi Kuba, Thanks for your advice in your previous letter. During last week, I have read the documents on Doxygen and the source code of the DomTreeBase/DomTree/PostDomTree/DeferredDominance class, I believe now I have a much better understanding on the relationship between these classes and how DeferredDominance class performs lazy updates. I have also learnt the current usage and drawbacks of

Hi, I'm looking for interprocedural AAs and have, of course, found https://llvm.org/docs/AliasAnalysis.html. However, the AAs that come bundled with LLVM do not work interprocedurally in a way that I need it (on/with stack variables). The two interesting looking AAs come with the optional `poolalloc' module that hasn't been updated in years (I guess

Hi Chijun, Great, seems like you did a lot of progress and understand the issues quite well! I have done some early sketch on the API of the new updater class. > From my current understanding, to solve the fragmentation problem of > the API, the new class first, need to maintain the DomTree and > PostDomTree class and deprecate the DefferredDominance class. > There are a couple of

On 4 November 2013 23:45, James Lyon <jameslyon0 at gmail.com> wrote: > I'm trying to build LLVM on Android rather than the other way around! > Really just to see if it can be done. I worked out the first problem (my > code was written for the old JIT and I'd missed something in updating to > the MCJIT to make it work on ARM). It still doesn't work, but at this