similar to: X86ISelLowering: Promote 'add nsw' to a wider type

Hi Sanjay, On 19 Jul 2016, at 18:54, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote: Hi Artur - I don't think there's any reason to limit the transform to sexts only; that's just the case that was apparent in https://llvm.org/bugs/show_bug.cgi?id=20134 , so I limited it to that pattern. It's probably worth noting that I'm

You are right: select in SDAG has to be poison-blocking as well, otherwise the current lowering from IR's select to SDAG's select would be wrong. Which makes the select->or transformation incorrect at SDAG level as well. I guess until recently people believed that poison in SDAG wasn't much of a problem (myself included). I was convinced otherwise with the test cases that

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

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

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

> 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

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

I agree. There’s implementation-defined behavior on the conversion of (arg*58) to int, but that shouldn’t be at issue here. The transform of (float)x + 1 => (float)(x + 1) is bogus. > On Mar 20, 2017, at 10:41 AM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks broken to me; I don't think there's UB in the original program. > > The fold in

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

This C program produces different results with -O0 and -O3 optimization levels. #include <stdio.h> float test(unsigned int arg) { return (float)((int)(arg * 58)) + 1; } int main() { printf("%d\n", (int)test((unsigned int)-831710640)); } O0 result is -994576896 O3 result is -994576832 It happens because LLVM (specifically instcombine) does the following transformation:

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

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,

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.

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

Hi, There are several optimizations where we try to load speculatively. There are also two similar functions to determine whether it's a safe transformation: * isSafeToLoadUnconditionally * isSafeToSpeculativelyExecute isSafeToLoadUnconditionally tries to take load alignment into account but fails to do this in some cases. It checks alignment for pointers derived from allocas and global

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

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

Hi Evan, The commit http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060327/033389.html broke CVS. The attached obvious patch fixes it. I don't have write access . So can someone commit this in ? ramana at zirakzigil:~/fsf/llvm/llvm/lib/Target/X86$ cvs diff -au X86ISelLowering.cpp Index: X86ISelLowering.cpp ===================================================================

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

My gut feeling is that it’s not worth it. When we move from typed to untyped pointers, we’re going to change the mangling from something like p200i8 to just p200, which is already quite a bit cleaner, and actually looks cleaner to me than the version proposed in this patch. David > On 24 Feb 2016, at 17:28, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This