similar to: [LLVMdev] ConstantExpr refactoring

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 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

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 Is it still valid/desired? -- cheers, --renato http://systemcall.org/

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:

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

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

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

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

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 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 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 particular case we are looking at is converting a pointer from one address space to another address space. There is one operand and one output, both are the same pointer type, except for their address space. The pointers are of the same size. The operation is a bit-changing operation. We are using intrinsic functions for the instructions. We need a solution for the ConstantExpr. Instead of

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

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.

That's an interesting idea. What are the essential differences between the new subclass and ConstantExpr? Will it end up like ConstantExpr? Or you want it to be ConstantExpr 'done right'? Thanks. Yuan -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Monday, December 17, 2012 5:40 PM To: Yuan Lin Cc: Chris Lattner; llvmdev at cs.uiuc.edu

On Thu, Jan 19, 2017 at 9:17 AM, Rackover, Zvi <zvi.rackover at intel.com> wrote: > Hi Sanjay, > > > > I agree we should also discuss **if** this canonicalization is beneficial. > > For starters, do we have a concrete case where we would benefit from > canonicalizing shuffles <-> truncates in LLVM IR? > > IMO, we should not count benefits for codegen

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 compiled thousands of test cases and many megabytes of C and

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,