similar to: [LLVMdev] faster?

Hi Luca, Don't use 'auto' in LLVM code for now. We still support building via some host compilers that don't support it. -Jim On Feb 3, 2012, at 7:31 AM, Luca Ciciriello <luca_ciciriello at hotmail.com> wrote: > Hi All. > > In my C++ code I'm using the libc++ library and my question is about which construct is faster: > > for(auto line : lines) >

I don't think he's asking about code in the compiler itself. In any case, the foreach loop doesn't evaluate "end()" every iteration of the loop. Depending in what the container is, that could be worse. My advice is to use the foreach loop and file a bug if you find a case that is ever slower. -Chris On Feb 3, 2012, at 10:06 AM, Jim Grosbach <grosbach at apple.com>

Ok, thanks Chris. Yes, my code not involve the compiler itself. Anyway the Jim advice is useful. Thanks again. Luca. On Feb 3, 2012, at 8:01 PM, Chris Lattner wrote: > I don't think he's asking about code in the compiler itself. In any case, the foreach loop doesn't evaluate "end()" every iteration of the loop. Depending in what the container is, that could be

Hi. Thanks. I changed the code but the problem exists. This is my new code which is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder>

LLVM is built in Release mode. The version is 6.0.0. I think that a similar code worked on verison 3.9.0. It is probably a null pointer dereference occurring in eraseFromParent(). I checked and reconfirmed that the instruction had no uses. Perhaps I should rebuild LLVM. Thanks. On Wed, Aug 8, 2018 at 9:03 PM, mayuyu.io <admin at mayuyu.io> wrote: > Hmmmm that’s strange. Do you get an

Thanks Bjorn! But The problem is still there. On Wed, Aug 8, 2018 at 2:04 AM, Björn Pettersson A < bjorn.a.pettersson at ericsson.com> wrote: > It looks quite dangerous to erase the instruction I inside the loop when > iterating over all instructions in the function. > I guess it depends on how the range based iterator is implemented if that > works or not. > > I think

Hi, supposing I have a function “foo” like the following: int foo(int a, int b) { ... ... } I want to insert int the LLVM IR a call instructions to a function “bar” that requires the same parameters of foo. So my function foo will become: int foo(int a, int b) { bar(a,b); … ... } I am using the following code: bool ThreadSanitizer::runOnFunction(Function &F) {

On Wed, Jun 19, 2013, at 03:49 PM, Olly Betts wrote: > On Wed, Jun 19, 2013 at 01:29:16PM +1000, Bron Gondwana wrote: > > The advantage of compact - it runs approximately 8 times as fast (we > > are CPU limited in each case - writing to tmpfs first, then rsyncing > > to the destination) and it takes approximately 75% of the space of a > > fresh database with maximum

Hi, I tried creating variable argument intrinsics which are to be placeholders for some instructions which should not be executed by the backend. Kindly help me with the errors in my "migrate_begin" intrinsic creation //Additions made to Intrinsics.td file: def llvm_migrate_begin : LLVMType<iAny>; def int_migrate_begin :

2013/8/8 Preston Briggs <preston.briggs at gmail.com> > > Hi, > > The DependenceAnalysis pass isn't reliable yet; it has several errors that > need to be corrected. These manifest by the analysis claiming there's no > dependence when one in fact exists. > > Your proposed scheme of testing every pair of instructions is > asymptotically expensive, requiring

On 02/12/2019 06:10 AM, Samuel Thibault wrote: > Hans van Kranenburg, le lun. 11 févr. 2019 22:59:11 +0100, a ecrit: >> On 2/11/19 2:37 AM, Dongli Zhang wrote: >>> >>> On 2/10/19 12:35 AM, Samuel Thibault wrote: >>>> >>>> Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: >>>>>> I have forwarded the original

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include

On 2/11/19 2:37 AM, Dongli Zhang wrote: > > On 2/10/19 12:35 AM, Samuel Thibault wrote: >> >> Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: >>>> I have forwarded the original mail: all VM I/O get stuck, and thus the >>>> VM becomes unusable. >>> >>> These are in many cases the symptoms of running out of "grant

Hello, Hans van Kranenburg, le sam. 09 févr. 2019 17:01:55 +0100, a ecrit: > > I have forwarded the original mail: all VM I/O get stuck, and thus the > > VM becomes unusable. > > These are in many cases the symptoms of running out of "grant frames". Oh! That could be it indeed. I'm wondering what could be monopolizing them, though, and why +deb9u11 is affected

Hi Lang, That would be great ! :) For now I found a hack which consist of loading a "full of NOP" DLL, use my own DllMemMgr which allocates JIT sections inside the DLL virtual space, backup the memory inside some buffers, unload the DLL, copy the buffer inside the DLL file, create the PDB, reload the DLL file which hopefully in 99% is reloaded at the same virtual address (this allow me

On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: > Author: hhinnant > Date: Fri Feb 14 15:09:01 2014 > New Revision: 201432 > > URL: http://llvm.org/viewvc/llvm-project?rev=201432&view=rev > Log: Remove myself as owner of libc++ > > Modified: > llvm/trunk/CODE_OWNERS.TXT > > Modified: llvm/trunk/CODE_OWNERS.TXT > URL:

So instead of using linkagetypes.weak I should use externalweaklinkage ? Le 11 févr. 2014 18:29, "Reid Kleckner" <rnk at google.com> a écrit : > You'd have to use extern_weak linkage. Clang compiles the foo declaration > to: > $ clang -cc1 -emit-llvm -o - t.c | grep declare.*@foo > declare extern_weak i32 @foo(...) #1 > > > > On Tue, Feb 11, 2014 at

Hi there, I am trying to interface c++ code in R and make a package. With R CMD SHLIB the dll was created, but when I try R CMD check, I am getting 'undefined reference to..' linkage error messages. The relevant c++ source from conf-infomap.cpp: #include "conf-infomap.h" #include "R.h" // R functions #include "Rinternals.h" #include "Rmath.h" //

Hi there, I'm sorry if I a send it for second time, I've just subscribed for the list. I am trying to interface c++ code in R and make a package. With R CMD SHLIB the dll was created, but when I try R CMD check, I am getting 'undefined reference to..' linkage error messages. The relevant c++ source from conf-infomap.cpp: #include "conf-infomap.h" #include

Hello, Sacha, le ven. 08 févr. 2019 18:00:22 +0100, a ecrit: > On  Debian GNU/Linux 9.7 (stretch) amd64, we have a bug on the last Xen > Hypervisor version: > > xen-hypervisor-4.8-amd64 4.8.5+shim4.10.2+xsa282 (Read: 4.8.5+shim4.10.2+xsa282-1+deb9u11) > The rollback on the previous package version corrected the problem: > > xen-hypervisor-4.8-amd64