search for: kuderski

> > 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 want to have LTO-like build, you can first...

...td::__1::allocator<char> > > > const&, > char const* const*) + 1159 > 6 lli 0x0000000104b94b84 main + 9104 > 7 libdyld.dylib 0x00007fff7d3cc015 start + 1 > Segmentation fault: 11 > > On Mon, Jan 28, 2019 at 10:40 AM Jakub (Kuba) Kuderski > <kubakuderski at gmail.com> 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: > >&...

...nd a pair of BB’s // (From and To). doSomethingWithTheUpdate(U); } Other CFG passes (e.g. LoopInfo, NewGVN) could also use it for testing. It would be also possible to hook it up to a fuzzer at some point in the future. What do you think about having such a utility in llvm? ~Kuba -- Jakub Kuderski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/19666de3/attachment.html>

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...

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

...CodeWriter should be the > one to do the bitcode version downgrade, right? > > Does this took work on LLVM 3.9svn? > > And could you give some hints about how you test the bitcode translator? > > Thanks > Hongbin > > > > > On Tue, Aug 2, 2016 at 3:25 PM, Jakub Kuderski < > kubakuderski+llvm at gmail.com> wrote: > >> I'm not sure if it was intended, but I think that you responded only to >> me (not to the list). >> >> Anyway, RenderScript currently uses llvm 3.2 IR as binary >> representation/exchangeable format, but t...

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 (+ 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 &g...

...; 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 to your reply. > > Regards, > Chijun > > 2018-03-15 1:42 GMT+08:00 Jakub (Kuba) Kuderski <kubakuderski at gmail.com>: > > 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 under...

...M 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 to your reply. Regards, Chijun 2018-03-15 1:42 GMT+08:00 Jakub (Kuba) Kuderski <kubakuderski at gmail.com>: > 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 pro...

Hi folks, We would like to add SeaHorn <http://seahorn.github.io/> and Crab-llvm <https://github.com/seahorn/crab-llvm> to the list of LLVM's users on http://llvm.org/Users.html under Open Source Projects. The descriptions would be: 1. SeaHorn | An Algorithmic Logic-Based Reasoning Framework. 2. Crab-llvm | A static analyzer based on abstract interpretation for LLVM. I attach a

...er to build bitcode from new version of LLVM IR. How do you think about this? At last, we also do not support exception handling:) Thanks. Hongbin On Tue, Aug 2, 2016 at 7:26 PM, Stephen Hines <srhines at google.com> wrote: > Hi Hongbin, > > On Tue, Aug 2, 2016 at 5:42 PM, Jakub Kuderski < > kubakuderski+llvm at gmail.com> wrote: > >> 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...

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

Hi mailing list, I has been working on a large project that is based on LLVM 3.1. Recently we are thinking to introduce an LLVM bc converter from LLVM 3.9 to LLVM 3.1, such that we can introduce some of the newest LLVM analyses and optimizations to our LLVM 3.1 based project. Have you worked on similar things that converting LLVM bc downward and has anything to share? Thanks Hongbin

...t; if you can give me some feedback on the proposal. > > Regards, > > Sagar > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- Jakub Kuderski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/1bc85e2b/attachment.html>

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 'C...

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 Tim and Alex Thanks for your replies. So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this? Thanks, Joan > On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev > <llvm-dev at

...gt;> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- Jakub Kuderski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180131/9bcc9fec/attachment.html>

...ol dependence and the difference between loop-dominance and dominance. Please keep me up-to-date with your work. This is really work that has long been overdue! Best, Tobias On Tue, Jun 13, 2017, at 10:23 AM, Tobias Grosser via llvm-dev wrote: > On Tue, Jun 13, 2017, at 09:22 AM, Jakub (Kuba) Kuderski via llvm-dev > wrote: > > Tobias, > > > > Thanks for the comments and taking a look at my fork. > > > > > > > - It would be convenient to allow .ll files to be read. > > > > Sure, I can add it tomorrow. > > Thank you! > > &g...

Hi, I am a first year M.Tech (computer science) student at IIIT Hyderabad. I am interested in working on the project - single updater class for the dominator tree in llvm and the algorithm for pruning unwanted changes to the Post Dominator Tree. I have gone through the programmers manual of llvm in the past and I have 3 years experience of working with the LLVM community. I have also gone