similar to: [LLVMdev] CBackend removal

Dear Jim and Owen, Thanks for replies, I only kindly suggest some discussion on the maillist in such cases. Just in general, nasty precedents sometimes happen, for example on IRC I've recently seen some commits to Objective C were requested to be reverted, because they were commited without any discussion. Here things are certainly not that hard, but the point is the same: it is always nice

Dear all, I've also noticed C backend was removed a little bit... silently. In the end of March I only got open bugs closed by Benjamin Kramer in bugzilla, but they sounded like "decision is made". So the question is: it such silent removal a normal practice? In times of 3.0 release there were long discussions on what to drop and what to preserve, e.g. sparc backend, if I remember

Hi Dmitry, Where were you expecting notice to have been given? If I recall correctly, the obsolescence of the C backend was mentioned many times on this mailing list, and as Owen notes, in the release notes since 2.8. I'm not trying to be snarky. You were obviously genuinely surprised by its removal, and that makes me wonder if where the core open source devs are expecting people to look for

> I'm periodically updating my local version of the LLVM, and, when I did it > today, I couldn't use the llc with -march=c. Looking for the CBackend files, > I realized that they were removed from the LLVM folder. I actually don't > remember reading about a drop of this capability in any of the devlist > messages, so I was wondering if this removal could be only

Oops, that's true: I forgot about that XD sorry =) Glad I could help, -- Cristianno Martins PhD Student of Computer Science University of Campinas cmartins at ic.unicamp.br <cristiannomartins at hotmail.com> On Tue, Jun 25, 2013 at 4:38 AM, Alexandru Ionut Diaconescu < cyrusthevirus001x at yahoo.com> wrote: > Hi Cristianno, > > Thank you, it works :) > > with

Hello Dmitry, First of all, thank you for your reply. Because of it, I focused in create the lib that helped me. Second, I realize that actually there was one thing different between the machines: due to a more frequent use of the iMac, I have a group of environment variables that are set to my developer folder; and the $PATH is one of those. Furthermore, it seems that my default compiler for

Hello again, Thanks for the responses =) Dmitry, I have two points to comment: - First, I applied these two patches, and the .cbe.c file came out ok, except for one little thing -- the global variable was created with both modifiers: static and extern. Then, I just added a single guard to prevent this to happen (in a case of a variable having local linkage, the "extern" part was not

Alexandru Ionut Diaconescu wrote: > Hi Cristianno, > > Thank you, it works :) > > with an extra cast: > Value *v ...... > ConstantInt* RR = (ConstantInt *)v; Please use "cast<ConstantInt>(v)" instead. See http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates . Nick > uint64_t VV = (RR->getValue()).getLimitedValue(); >

Hi Cristianno, On 01/06/13 01:49, Cristianno Martins wrote: > Hello there, > > I'm writing a transformation pass for LLVM, and I hoped to use dce to clean up > the resulting code after my pass. I just have some questions about LLVM's dce > implementation. > > Well, my transformation is a function pass, and, after the changes are made, > some instructions are not

Hi Rasha, First, you should not erase that cloned function XD the idea is that your pass should create that new function, add it to a module (that could be the same one where the original function is, or another one that you could be creating if that is the case), and then just let it be: the pass manager should identify this new function (after your pass returned) and all the other analysis and

Hi Cristianno, Thank you, it works :) with an extra cast:                                     Value *v ......                                     ConstantInt* RR = (ConstantInt *)v;                                     uint64_t VV = (RR->getValue()).getLimitedValue();                                     errs()<<"\nRR  "<<VV<<"\n";

Hi Cristianno, This problem has been around for a while, ourselves we solve it with the following patches: https://hpcforge.org/scm/viewvc.php/trunk/patches/llvm.gpu.patch?root=kernelgen&view=markup https://hpcforge.org/scm/viewvc.php/trunk/patches/llvm.patch?revision=591&root=kernelgen&view=markup Please feel free to apply them, they *should* work for you even with the latest llvm

Hello there, I'm writing a transformation pass for LLVM, and I hoped to use dce to clean up the resulting code after my pass. I just have some questions about LLVM's dce implementation. Well, my transformation is a function pass, and, after the changes are made, some instructions are not needed anymore. In order to easily get rid of those instructions, I'm setting all their uses to

Hello again, So, after some changes, I inserted intentionally values with use in other modules, and I get the following error: While deleting: i1 % Use still stuck around after Def is destroyed: %c = phi i1 [ false, <badref> ] [...] Assertion failed: (use_empty() && "Uses remain when a value is destroyed!"), function ~Value, file

Hi Alexandru, if you have a Value pointer named v, you could use the method v->getValue(). getLimitedValue(), which returns uint64_t, that can be casted as int. Hope I could help, -- Cristianno Martins PhD Student of Computer Science University of Campinas cmartins at ic.unicamp.br <cristiannomartins at hotmail.com> On Tue, Jun 25, 2013 at 4:05 AM, Alexandru Ionut Diaconescu <

Hello everyone, I've been trying to generate a C file using the llc tool, but I'm having a problem. I'm using a single Hello World program in C, and executing the following passes: clang -emit-llvm -c -o hello.bc hello.c  # getting the bit code of hello.c llc -march=c hello.bc                          # generating the hello.cbe.c file using the llvm C backend So far, nothing weird

Hi, Depending on what have run before your pass, the loop may have been unrolled or simplified if the computation inside the loop is too simple. Cheers, -- Arnaud de Grandmaison ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Cristianno Martins [cristiannomartins at gmail.com] Sent: Thursday, April 26, 2012 5:52 PM To:

On Tue, May 14, 2013 at 11:42 AM, Cristianno Martins < cristiannomartins at gmail.com> wrote: > Hello there, > > I'm trying to use a simple implementation of a queue (my own > implementation of it, actually), and I'm trying to use the functions > defined on my queue class inside some llvm-ir code. Unfortunately, the > names of the functions are being messed up,

Oh, ok, sorry but only now I understood your list will be used by the programmers functions on his code, and not on your pass code for llvm while your pass is being compiled XD Ok, once I had a similar problem, and I resolved it by creating a mini API in C++ with some classes that encapsulated lists of integer, floating point or pointer types (I actually needed three different classes for those

Hi Rinaldini, In order to find information about loops inside a given function you should use something like "LoopInfo *LI = P->getAnalysis<LoopInfo>()", remembering to add "AU.addRequired<LoopInfo>();" to your getAnalysisUsage method. If the function you are interested to is not located in the module being compiled (if you created it as an auxiliary function,