similar to: [LLVMdev] llvm-gcc ignores function attributes of template functions?

On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > On Tuesday 13 July 2010 19:48:25 you wrote: >> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >> > I thought that the layout of structs was supposed to be preserved (wrong >> > assumption?). Otherwise, any ideas why this happens? >> >> It should be preserved in

On Tuesday 13 July 2010 19:48:25 you wrote: > On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel > > I thought that the layout of structs was supposed to be preserved (wrong > > assumption?). Otherwise, any ideas why this happens? > > It should be preserved in general; Is this a "should" or a "must"? Are there any cases in which structure layout must be

On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel > <torvald at se.inf.tu-dresden.de> wrote: >> On Tuesday 13 July 2010 19:48:25 you wrote: >>> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >>> > I thought that the layout of structs was supposed to be preserved (wrong

On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >> <torvald at se.inf.tu-dresden.de> wrote: >>> On Tuesday 13 July 2010 19:48:25 you wrote: >>>> On Tue, Jul 13, 2010 at 10:09

Hi, I would like to prevent that two adjacent calls to external functions getting interleaved/separated by other neighboring code. This mixing seems to happen in the code generator. I can prevent it by putting the two calls into a separate BB, but then I can't use -simplifycfg, -jump-threading, ... as is. Here is an example: %160 = add i64 %158, %159 ; <i64>

On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >>> <torvald at se.inf.tu-dresden.de> wrote:

On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > Hi, > > attached is small program in which padding inside a struct is lost when using > llc, but is not lost when using llvm-gcc or gcc. In particular, padding is > missing after codegen with llc (see (1) below, LLVM 2.7, Linux x86_64): > typedef struct { >    unsigned txnal; >

Hi, attached is small program in which padding inside a struct is lost when using llc, but is not lost when using llvm-gcc or gcc. In particular, padding is missing after codegen with llc (see (1) below, LLVM 2.7, Linux x86_64): typedef struct { unsigned txnal; char padding[64]; unsigned nontxnal; } Data; Data data; I thought that the layout of structs was supposed to be preserved

On Wednesday 14 July 2010 17:57:26 Andrew Lenharth wrote: > On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> Is alignment on a field

Hi Vikram, I want to use poolalloc as a means for partitioning memory in Software Transactional Memory. We will have a paper about tuning parameters in word-based STMs in PPoPP 08, but there we use one configuration for the complete TM, which obviously has limitations in heterogenous workloads. Partitioning with poolalloc should give me (1) hopefully meaningful partitions (ie,

Hi, I recently looked quite some time for why poolalloc wouldn't transform calls to malloc() in my program, until I noticed that it handles calls to malloc() (eg, stdlib pass) -- but only transforms MallocInst's. Is there a general policy on how passes should behave? Should they handle both representations, is doing -raiseallocs the preferred way, or do we explicitely not want any

I would like to announce the availability of compiler support for generation of transactional code in LLVM IR. Our tool is called Tanger and it is an LLVM pass. You can download Tanger at: http://tinystm.org Transactional memory (TM) is viewed by a lot of people to be an important tool for enabling parallelism in a wide area of applications, and especially for developers that are not skilled

On Wednesday 01 April 2009 20:01:09 Dan Gohman wrote: > On Apr 1, 2009, at 7:25 AM, Torvald Riegel wrote: > > On Wednesday 25 March 2009, Luke Dalessandro wrote: > >> You could encode this information as simple library function calls > >> and > >> then find them again in the generated LLVM IR. The client then just > >> needs a header declaring the

Torvald Riegel wrote: > On Thursday 11 June 2009 18:14:08 John Criswell wrote: > >> If your use of pool allocation requires that you can always get the pool >> handle for a pointer, you need to make sure that pool allocation is >> configured so that it doesn't generate the above scenario. I think >> there is an option to make all pools be global pools.

On Thursday 11 June 2009 18:14:08 John Criswell wrote: > If your use of pool allocation requires that you can always get the pool > handle for a pointer, you need to make sure that pool allocation is > configured so that it doesn't generate the above scenario. I think > there is an option to make all pools be global pools. Some time ago, I used AnalysisUsage's

Torvald, For what are you interested in poolalloc? I'm asking because we are trying to decide how to prioritize work on it. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Oct 27, 2007, at 11:10 AM, Torvald Riegel wrote: > Hi, > > I recently looked quite some time for why poolalloc wouldn't > transform calls > to malloc() in my program, until I

On Monday 17 December 2007, Christopher Lamb wrote: > On Dec 17, 2007, at 1:22 AM, Torvald Riegel wrote: > > Would it be possible to keep get() unchanged, with a default > > behaviour, plus > > a warning? Otherwise everybody (assuming everybody gets type void*) > > will > > have to update their LLVM passes, and either maintain two versions > > of the >

Hi, I have two related questions: Are there LLVM developers on this list that are interested in improving LLVM performance? I have examples in which LLVM is slower than gcc (e.g., STM linked list microbenchmark, 1.8 (gcc) vs. 1.3 (llvm), more is better). I've never done compiler performance tuning, so I don't know how much effort is required. Second question: does anyone keep track

On Wednesday 25 March 2009, Luke Dalessandro wrote: > You could encode this information as simple library function calls and > then find them again in the generated LLVM IR. The client then just > needs a header declaring the functions and information on what they > mean. Since there are never any definitions of them they won't end up > going anywhere. I've been using this

On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: > Anyone have an idea? The patch as it stands is attached below. X86 > is a pseudo instruction because the necessary ones and prefixes aren't > in the code gen yet, but I would imagine they will be (so ignore that > ugliness). The true ugliness can be seen in the alpha impl which open > codes it, including a couple