similar to: [LLVMdev] ConstantExpr refactoring

Yes, that's definitely still desired. I wouldn't say it is "low impact" though :) -Chris On Apr 14, 2012, at 8:17 AM, Renato Golin wrote: > Hi all, > > After 6 months away, I'm looking for some low impact, unimportant area > of LLVM to get back in sync with the code base. > > Is anyone looking at this bug: http://llvm.org/bugs/show_bug.cgi?id=10368

Hi all, It's been a long time, and I'm probably going to kill myself, but I want to try it anyway. Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, and that this is source of many problems (most notably with traps) and code duplication. However, I'm a bit lost... There seem to be constant folding in many places like ConstantExpr::get*() uses

On Fri, Jun 29, 2012 at 3:10 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. > > Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, > and that this is source of many problems (most notably with traps) and > code duplication.

On Fri, 29 Jun 2012 23:10:39 +0100 Renato Golin <rengolin at systemcall.org> wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. > > Bug 10368 [1] tells me that ConstantExpr shouldn't automatically fold, > and that this is source of many problems (most notably with traps) and > code

On 29 June 2012 23:40, Hal Finkel <hfinkel at anl.gov> wrote: > This seems like yet-another place where target-information integration > would be helpful (and, indeed, should be used). Indeed! And it's part of the plan, to make sure we get it right. However, since all folding will eventually be moved to the function pass, that's gotta be coded (if not there yet) on the pass. I

Renato Golin wrote: > Hi all, > > It's been a long time, and I'm probably going to kill myself, but I > want to try it anyway. I don't think that turning off folding of constants is the right place to start. To implement this, start by adding new constants that are going to replace the existing ones. A good rule of thumb is "whatever the relocations in a given

On Sat, 30 Jun 2012 13:10:47 +0100 Renato Golin <rengolin at systemcall.org> wrote: > On 29 June 2012 23:40, Hal Finkel <hfinkel at anl.gov> wrote: > > This seems like yet-another place where target-information > > integration would be helpful (and, indeed, should be used). > > Indeed! And it's part of the plan, to make sure we get it right. > However,

I am looking for a way to allow ConstantExpr to express target specific operations, which will be used in global initializers. The recommended way to extend LLVM IR is using intrinsic functions. But this does not work for ConstantExpr, which the global initializer uses. Should we make ConstantExpr to support some kind of side-effect free intrinsic function calls? If we want to work on such a

On Dec 17, 2012, at 11:26 AM, Yuan Lin <yulin at nvidia.com> wrote: > I am looking for a way to allow ConstantExpr to express target specific operations, which will be used in global initializers. > > The recommended way to extend LLVM IR is using intrinsic functions. But this does not work for ConstantExpr, which the global initializer uses. > > Should we make

On 30 July 2012 09:34, Renato Golin <rengolin at systemcall.org> wrote: > The tentative date for the next Cambridge LLVM Social is Wed 22nd > October, 7:30pm at the Cambridge Blue. Of course, I meant August. Thanks Igor for the correction!! -- cheers, --renato http://systemcall.org/

I will be there again! On 30 July 2012 10:35, Renato Golin <rengolin at systemcall.org> wrote: > On 30 July 2012 09:34, Renato Golin <rengolin at systemcall.org> wrote: > > The tentative date for the next Cambridge LLVM Social is Wed 22nd > > October, 7:30pm at the Cambridge Blue. > > Of course, I meant August. Thanks Igor for the correction!! > > -- >

Ok, I got the benchmark to work on test-suite, but it's not printing details for each run (or execution wouldn't work). I had to comment out the printf lines, but nothing more than that. I'm not sure how individual timings would have to be extracted, but the program produces output via text file, which can be used for comparison. Also, it does check the results and does report if they

The tentative date for the next Cambridge LLVM Social is Wed 22nd October, 7:30pm at the Cambridge Blue. http://www.the-cambridgeblue.co.uk/blueroadmap.html If you haven't done so yet, you can subscribe to our calendar to know when the next one will be: https://www.google.com/calendar/embed?src=as5fh066i94qthrkct1lv7rojo%40group.calendar.google.com&ctz=Europe/London Most people feel

On Mon, Dec 3, 2012 at 1:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > Apart from what has already being said, which I agree mostly, I have > some specific comments: > > >> a. We change the test suite to run in such a way that all tools default to >> an "unknown" host triple. > > The assumptions will be different and I believe the

Sorry for the massive delay on this... did this thread at least fix your immediate problem? It may be a while until I can get to writing a "workflows" page. -- Sean Silva On Mon, Dec 31, 2012 at 9:07 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 1 January 2013 02:03, Sean Silva <silvas at purdue.edu> wrote: >> I'm not sure if this was clear from my

That would be great! On Nov 5, 2012, at 2:11 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 5 November 2012 17:41, Nadav Rotem <nrotem at apple.com> wrote: >> 1. We do not allow reductions on floating point types. We should allow them when unsafe-math is used. >> 2. All of the arrays are located in a struct. At the moment we don't detect that these

On 2011-02-14 20:39, Talin wrote: > > > On Mon, Feb 14, 2011 at 1:17 AM, Renato Golin <rengolin at systemcall.org > <mailto:rengolin at systemcall.org>> wrote: > > I think this deserves a blog post... > > I'd like to wait until I get some feedback - I don't know yet if anyone > is having trouble building or running the thing... Hi Talin,

On Thu, Sep 29, 2011 at 9:39 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 29 September 2011 13:54, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > Did you try to re-run configure after pulling that commit? > > I just tried a shared build with: > > ../configure --enable-optimized --enable-assertions > > --enable-targets=host,ptx

Thank you very much for you help, Renato! I read through paper you referred and also this document - http://llvm.org/docs/tutorial/JITTutorial1.html Following these instructions to create successful function I run into some problems: 1) llvm::getGlobalContext() does not exists anymore? "llvm/LLVMContext.h" too? 2) creating instance of IRBuilder don't require template (from tutorial

Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at