similar to: [LLVMdev] Speculative loads and alignment

Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as

Hi Sanjay, Some time ago you implemented a sext(add_nsw(x, C)) --> add(sext(x), C_sext) transformation in X86ISelLowering https://reviews.llvm.org/D13757 Is there any reason why this transformation is limited to sexts and doesn’t support zexts? Thanks, Artur -------------- next part -------------- An HTML attachment was scrubbed... URL:

Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko < apilipenko at azulsystems.com> wrote: > Are you going to run some of the existing passes? Why can’t you just use > the returned change-made value from the passes? > > Artur > > > On 20 Dec 2015, at

Hi, On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: ----- Original Message ----- From: "Artur Pilipenko" <apilipenko at azulsystems.com<mailto:apilipenko at azulsystems.com>> To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Cc: "Hal Finkel" <hfinkel at anl.gov<mailto:hfinkel at

> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to function arguments, or does that not work currently? We can’t, no. I have an out of tree patch which allows metadata in AttributeSets. This would also potentially also work here. However, depending on the number of unique

Per my previous email, I have just signed off on Artur's original patch. Philip On 03/02/2016 11:21 AM, Philip Reames via llvm-dev wrote: > Elena, > > I'd like to propose that we move forward withArtur's original patch > <http://reviews.llvm.org/D17270> and separate the discussion of how we > might change our intrinsic naming scheme. Artur's patch is

Hello, For the Glasgow Haskell Compiler's backend, we would like to let LLVM know that certain loads are safe to execute speculatively and hence to hoist out of loops. At the moment, there doesn't seem to be a mechanism for doing so. There seem to be two ways of implementing this: either allow arbitrary instructions to be marked as safe and have Instruction::isSafeToSpeculativelyExecute

Ok, thanks. Are there any plans to reintroduce it on the IR level? I'm not confident this is strictly necessary, but in some cases not having load widening ends up really bad. Like in the case where vectorizer tries to do something about it: https://godbolt.org/z/60RuEw https://bugs.llvm.org/show_bug.cgi?id=42708 At the current state I'm forced to use memset() to express uint64 load from

Hi, I’d like to support string attributes on function arguments and return values. We are going to use them in our tree to express higher level language types. Internally attributes framework have everything to do this, it’s even possible to generate string attributes via API right now: Function *function; function->setAttributes(function->getAttributes().addAttribute(context, i,

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other

On Tue, Jul 14, 2015 at 9:01 PM Philip Reames <listmail at philipreames.com> wrote: > On 07/14/2015 05:07 PM, Pete Cooper wrote: > > > On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to > function arguments, or does that not work currently? > > We can’t, no.

On Jan 23, 2012, at 4:22 AM, Roman Leshchinskiy wrote: > Hello, > > For the Glasgow Haskell Compiler's backend, we would like to let LLVM know > that certain loads are safe to execute speculatively and hence to hoist > out of loops. At the moment, there doesn't seem to be a mechanism for > doing so. There seem to be two ways of implementing this: either allow >

Hi, Can I ask what is the status of load widening. It seems there is no load widening on IR at all. // Paweł On Wed, Oct 5, 2016 at 1:49 PM Artur Pilipenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Philip and I talked about this is person. Given the fact that load > widening in presence of atomics is irreversible transformation we agreed > that we don't want to do

| (canonicalizeOperands swaps arguments of an and and then ReassociateExpression swaps them back). That feels like its own bug, canonicalize and reassociate having different opinions of canonical order. Just saying. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Artur Pilipenko via llvm-dev Sent: Monday, December 21, 2015 9:11 AM To: Russell Wallace Cc: llvm-dev

This buildbot appears to have been failing for several weeks now ( http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/19490 ). Does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 11:17 PM Subject: buildbot failure in LLVM on clang-ppc64-elf-linux2 To: Aaron Ballman <aaron at

If we do load combining at the IR level, one thing we'll need to give some thought to is atomicity.  Combining two atomic loads into a wider (legal) atomic load is not a reversible transformation given our current specification. I've been thinking about a concept I've been tentatively calling "element wise atomicity" which would make this a reversible transform by

On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on

This probably needs broader discussion. We have an existing naming mechanism for polymorphic intrinsics; Elena is proposing a new one to avoid making the names for various load/store intrinsics particularly ugly. My personal take: 1) I like the cleaner naming scheme. 2) I'm not sure the additional complexity is worth it. (Not specific to the particular implementation proposed here.) 3) I

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other