similar to: [LLVMdev] Deduplication of memory allocation

Hi, I’ve made my own version of std::vector which is called il::Vector. Due to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html>, LLVM can optimise away memory allocation. Therefore, the following code optimise away all memory allocation for w resulting in a single allocation during the whole program (for

Hi, I’ve made my own version of std::vector which is called il::Vector. Due to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html>, LLVM can optimise away memory allocation. Therefore, the following code optimise away all memory allocation for w resulting in a single allocation during the whole program (for

Hi, I want an efficient way to implement function pow in LLVM instead of invoking pow() math built-in. For algorithm part, I am clear for the logic. But I am not quite sure for which parts of LLVM should I replace built-in pow with another efficient pow implementation. Any comments and feedback are appreciated. Thanks! -- Wei Ding -------------- next part -------------- An HTML attachment was

> It is not clear what the test-case is (what source, what compiler options). My suspicion is that your differences are in the noise, and most of the time is spent doing other things than hashing. Did you profile the a run, and check how much of the total time is spent in the hash-function [you may need to tweak the code a bit to not inline the actual hash function]. Also publishing the RANGE

> On Jan 10, 2017, at 2:31 AM, Chris Lattner <sabre at nondot.org> wrote: > > As others have pointed out, 37 does have some nice properties (by being prime), but we’ve also had it from the very early days. I wouldn’t say that it has been extremely well considered at all. > > -Chris Thanks for your reply. But I am not sure to understand the last sentence. Does it mean that

> On Jan 10, 2017, at 8:56 AM, Mehdi Amini <mehdi.amini at apple.com> wrote > > Some tests I can suggest is to replace the hash function with your favorite and: Thanks. I’ll give it a try. It will take some time as I need to rewrite DenseMap if I want to use the Knuth multiplicative hash. > ultimately I believe real-world impact is the best way to get a change in. That’s

On 17 August 2017 at 15:27, Hal Finkel <hfinkel at anl.gov> wrote: > Speaking of benchmarks, we might be able use the library, or some parts of > it, in our test suite for correctness and performance testing. I see some > stand-alone benchmarks that seem useful (e.g., > https://github.com/insideloop/InsideLoop/blob/master/il/benchmark/types/32-vs-64-bit-integers.cpp) > but

Hi, Let me present myself : I work on High Performance Computing, mainly on number crunching where the languages used are mainly Fortran and C++. This field is moving more and more from pure number crunching where Fortran shines to a mix of numbers, texts and other data that you cannot easily deal with Fortran. Unfortunately, the C++ standard library suffers from its age and the fact that it has

Hi, I’ve been looking at Chandler Carruth talks about internal data structures for LLVM in order to implement my own library. That’s how I ended up looking at the internals of DenseMap and the default hash functions defined in DenseMapInfo. I have been very surprised by the hash function used for integers which is hash(k) = 37 * k. This kind of hashing function does not change the lowest bits of

> On Jan 10, 2017, at 9:36 AM, Bruce Hoult <bruce at hoult.org> wrote: > > Both are not very sophisticated. > You should also look at the different MurmurHash versions, and descendants such as CityHash. I did a few benchmark this morning, trying to tweak the hashing for pointers (as many people seem to use pointers as keys). The hash function in LLVM is quite simple, but it

I’ve missed it. I did a quick search and the only thread I found is back from 2013. Could you please provide me with a link to the thread? François Fayard Founder & Consultant - Inside Loop Tel: +33 (0)6 01 44 06 93 <tel:+33%206%2001%2044%2006%2093> Web: www.insideloop.io <http://www.insideloop.io/> Twitter: @insideloop_io > On 06 May 2015, at 07:21, David Blaikie <dblaikie

Hi Dean. Thanks for your reply. The ADT library is exactly what I end up replicating. My library started 2 years ago and at the beginning, what I needed was very different from LLVM. My first containers were: - A custom std::vector that does not initialize elements to 0 for int, double, etc. This is very important in HPC for the first touch policy used on NUMA architectures. It also allows

> You can imagine a community the size of LLVM's having to rely on > external libraries that may have the same goals today, but different > paths tomorrow. The end result is the same: a fork for the things that > matter to us, just like we've done with the standard library. > > All in all, your library looks really nice, and it does solve an > intersection of the

On Oct 1, 2012, at 9:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Using GEP on an i8* is a bit nicer to the optimizer, though, because > using ptrtoint/inttoptr has effects on alias analysis. My understanding is that, in order to use GEP, you have to provide the LLVM code with the struct layout, i.e., build a StructType object. In my case, that struct is declared in C++

Given the C++ struct: struct S { string a; string b; }; I also have C "thunk" functions that I call from LLVM code: // calls S::S() void* T_S_M_new( void *heap ); // call string::assign(char const*) void T_string_M_assign_Pv( void *that, void *value ); I want to do the LLVM equivalent of the following C++ (where that 's' is pointer to an instance of 'S'):

On Tue, Oct 2, 2012 at 11:33 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > On Oct 1, 2012, at 9:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> Using GEP on an i8* is a bit nicer to the optimizer, though, because >> using ptrtoint/inttoptr has effects on alias analysis. > > My understanding is that, in order to use GEP, you have to provide the

i removed printf from loop. Now getting no error. but the IR doesnot contain vectorized code. IR Output is as follows: ; ModuleID = 'sum-vec.ll' source_filename = "sum-vec.c" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: norecurse nounwind readnone uwtable define i32 @main(i32, i8**

On 31.05.2011 19:45, Devang Patel wrote: > > On May 31, 2011, at 10:36 AM, trash-stuff at gmx.de > <mailto:trash-stuff at gmx.de> wrote: > >> On 31.05.2011 19:22, Devang Patel wrote: >>> >>> On May 30, 2011, at 11:11 AM,trash-stuff at gmx.de >>> <mailto:trash-stuff at gmx.de>wrote: >>> >>>> Hi all, >>>>

On Mon, Oct 1, 2012 at 9:33 PM, Paul J. Lucas <paul at lucasmail.org> wrote: > Given the C++ struct: > > struct S { > string a; > string b; > }; > > I also have C "thunk" functions that I call from LLVM code: > > // calls S::S() > void* T_S_M_new( void *heap ); > > // call

On Oct 2, 2012, at 2:34 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Oct 2, 2012 at 11:33 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > >> My understanding is that, in order to use GEP, you have to provide the LLVM code with the struct layout, i.e., build a StructType object. In my case, that struct is declared in C++ code already and, in order to