similar to: [LLVMdev] canonicalizing add in constant expressions

On Fri, 2 May 2008, Jay Foad wrote: > I wrote some code that fell over when it encountered this ConstantExpr: > i32 add (i32 24, i32 ptrtoint ([20 x %"struct.stlpmtx_std::string"]* > @_ZN12BulletMLNode11name2stringE to i32))) > > because it expected the LHS of the add to be another ConstantExpr. (This is > the first time that bit of code has fallen over, despite having

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

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Hey everyone, I'd like to add some new constant foldings to ConstantExpr -- in particular ConstantExpr::get(...) and friends. But, I'm having trouble finding the correct place for adding IR tests in the /test directory. Any suggestions? Thanks, Cam -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am trying to implement if-conversion as an LLVM pass. My reference is Chapter 7 of the book ""Optimizing Compilers for Modern Architectures", based on the suggestion here: https://groups.google.com/d/msg/llvm-dev/FlDGnqSGbR8/eH5hO9IBbXYJ Some steps in the if-conversion pass require simplification of Boolean Expressions. Is this doable within the LLVM API? llvm::ConstantExpr seems

The LLVM Module has an optional target triple and target datalayout. Without them, an llvm::DataLayout can't be constructed with meaningful data. The benefit to making them optional is to permit optimization that would work across all possible DataLayouts, then allow us to commit to a particular one at a later point in time, thereby performing more optimization in advance. This feature is not

On 30 January 2014 09:55, Philip Reames <listmail at philipreames.com> wrote: > On 1/29/14 3:40 PM, Nick Lewycky wrote: > >> The LLVM Module has an optional target triple and target datalayout. >> Without them, an llvm::DataLayout can't be constructed with meaningful >> data. The benefit to making them optional is to permit optimization that >> would work

I can't upload my program due to confidentiality, but the problem is obvious. At lib/Analysis/ConstantFolding.cpp:646 Constant *C = ConstantExpr::getGetElementPtr(Ops[0], NewIdxs); if (ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) { if (Constant *Folded = ConstantFoldConstantExpression(CE, TD, TLI)) C = Folded; } The generated ConstantExpr C doesn't inherit the

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

On 5 February 2014 09:45, Philip Reames <listmail at philipreames.com> wrote: > On 1/31/14 5:23 PM, Nick Lewycky wrote: > > On 30 January 2014 09:55, Philip Reames <listmail at philipreames.com> wrote: > >> On 1/29/14 3:40 PM, Nick Lewycky wrote: >> >>> The LLVM Module has an optional target triple and target datalayout. >>> Without them, an

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 Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

Hi, All. Does anybody know about ConstantExpr in llvm? What's it? Since it always appears after llvm optimization such as -O2 level, what is it supposed to be to codegen? I am wondering it represents constant value which can be determined or computed at compile-time(actually is link-time) to improve performance. Although we do not know the actual constant value util the object file is linked.

To the right list this time. On Tue, Oct 18, 2016 at 12:43 PM Eric Christopher <echristo at gmail.com> wrote: > Hi Peter, > > Coming back to his now. > > > IFCC, the previous attempt to teach LLVM to emit jump tables, was removed > for complicating how functions are emitted, in particular requiring a > subtarget-specific instruction emitter available in

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp index 58092f4..93f7c2a 100644 ---

Hi Duncan, Thanks for pointing out my mistake. I will reword my questions. //C code int var1; //global int a, b; foo(a, b); bar(c); generates following //LLVM IR %1 = load a; %2 = load b; call foo(%1, %2) call bar(@var1) CallInst.getOperand(1).getNameStr() on foo, returns null, but on bar returns var1. Similarly, for call void @p_ptr(i64 ptrtoint (%struct.my_struct* @abc to i64)) nounwind,

On Sun, Jan 11, 2015 at 4:40 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 > > Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> > --- > V2: Split out F64 parts > V3: remove handling of saturate for (U/S)32, > >

On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > You can easily simplify this problem with a restriction in SPIR: disallow ConstantExpr casts - no ptrtoint constant expression. Because GlobalVariables have pointer type, if you disallow converting their type to non-pointer type in a constantexpr, the number of constantexpr subclasses you have to deal with is

Sounds good, I'll reword that comment. Also, the assert you mentioned turned out to be a bad assumption when combined with how I foresee us handling inttoptr/ptrtoint in the future, so I'll just replace it with slightly more robust code. :) Thanks for the feedback, George On Tue, Feb 3, 2015 at 11:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi George, > > +// Given an

On Fri, Jan 2, 2015 at 2:20 AM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Fri, Jan 2, 2015 at 1:58 AM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> Hi! >> LLVM has a class, ConstantExpr, that is very handy for compile-time >> evaluation of const expressions. Unfortunately I cannot find any methods >> in it that would be