search for: pilipenko

...isit the load pair first, you really want to be able to split them again once you discover the store. Note that the same theoretical problem exists in MI/SelectionDAG.  We just do so much less memory optimization there we get away with mostly not caring.  :) Philip On 9/24/2019 4:50 PM, Artur Pilipenko via llvm-dev wrote: > Implementing load combine/widening on the IR level sounds like a > reasonable enhancement to me. Although, we (Azul) don't have any plans > of doing that in the near future. > > Artur > >> On 12 Sep 2019, at 00:58, Paweł Bylica <chfast at gmail...

...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 an array of bytes. // P. On Thu, Sep 12, 2019 at 4:22 AM Artur Pilipenko <apilipenko at azul.com> wrote: > Hi, > > Load widening/combine for the original pattern was implemented in DAG > combiner. See: > > https://github.com/llvm/llvm-project/blob/23bbeb52f392d88bf0d0527392a7a11561ee09c0/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L6872 > &...

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 this early. For now it can be implemented as a > peepho...

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 15:43, Russell Wallace via llvm-dev < > llvm-dev at lists.llvm.or...

> On 29 Sep 2016, at 21:01, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko wrote: > > > BTW, do we really need to emit an atomic load if all the individual > > components are bytes? > > Depends -- do you mean at the at the hardware level or at the IR > level? > > If you mean at the IR level, then I think yes; since otherwise it is > leg...

...do, but doing it as a CGP like fixup pass over the IR is also reasonable. > > With that in mind, I feel both the current placement of LoadCombine (within the inliner iteration) and the proposed InstCombine rule are undesirable. > > Philip > > > On 09/28/2016 08:22 AM, Artur Pilipenko wrote: >> Hi, >> >> I'm trying to optimize a pattern like this into a single i16 load: >> %1 = bitcast i16* %pData to i8* >> %2 = load i8, i8* %1, align 1 >> %3 = zext i8 %2 to i16 >> %4 = shl nuw i16 %3, 8 >> %5 = getelementptr inbounds i8,...

Masked load/store are overloaded intrinsics, the only generic type is the type of the value being loaded/stored. The signature of the intrinsic is generated based on this type. The type of the pointer argument is generated as a pointer to the return type with default addrspace. E.g.: declare <8 x i32> @llvm.masked.load.v8i32(<8 x i32>*, i32, <8 x i1>, <8 x i32>) The

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 anl.gov>> Sent: Monday, July 13, 2015 6:45:35 AM Subject: String attri...

> On 29 Sep 2016, at 03:23, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko via llvm-dev wrote: > > 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. > > I don't think this...

...t when converted back using fptosi, then the transform does not work. > > define float @test(i32 %x) { > %mul = mul i32 %x, 58 > %conv = sitofp i32 %mul to float > %add = fadd float %conv, 1.0 > ret float %add > } > > > On Mon, Mar 20, 2017 at 4:25 AM, Artur Pilipenko <apilipenko at azul.com <mailto:apilipenko at azul.com>> wrote: > 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...

...nonicalizeOperands 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 Subject: Re: [llvm-dev] Hash of a module There is a caveat here. I was experimenting with something similar and found that this status is not always trustworthy. I fixed one bug in prune-eh. These is also a bug i...

...e a significant number of sets which could get slow. Metadata attached to the function or the function arguments is likely to scale better than strings/metadata in the AttributeSets, but I guess it all depends on whether many are even needed. Pete > > On Mon, Jul 13, 2015 at 7:42 AM, Artur Pilipenko <apilipenko at azulsystems.com <mailto:apilipenko at azulsystems.com>> wrote: > Hi, > >> On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> >> ----- Original Message ----- >>> From: "Artur P...

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:

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

...interested to see what kinds of patterns you're seeing and want to optimize. It's possible that IR transforms could eliminate the need for the backend fixups...or it could make them harder. Are there bug reports for the cases that you are looking at? On Tue, Jul 19, 2016 at 9:13 AM, Artur Pilipenko <apilipenko at azulsystems.com<mailto:apilipenko at azulsystems.com>> wrote: 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 limit...

...n attributes seem to make the best sense. Mostly just trying to see about you getting the right fixes in for the support you need and the rest of us not having to worry about not breaking things that no one cares about :) -eric > Philip > > > On Mon, Jul 13, 2015 at 7:42 AM, Artur Pilipenko < > apilipenko at azulsystems.com> wrote: > >> Hi, >> >> On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov> wrote: >> >> ----- Original Message ----- >> >> From: "Artur Pilipenko" <apilipenko at azulsystems.com> &g...

On 04/19/2016 09:35 AM, Ahmed Bougacha wrote: > On Mon, Apr 18, 2016 at 4:28 PM, Philip Reames > <listmail at philipreames.com> wrote: >> >> >> On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: >> >> On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Does this sound reasonable? Are there any other alternatives? >> Would demoting pointer types to pNi8 work? >> >> As you say, that could potentially mask problems, but I don't think the type of the masked load...

I'm looking at the bug (https://llvm.org/bugs/show_bug.cgi?id=31181) which was triggered by my change to make CVP mark adds as no wrap (https://reviews.llvm.org/rL278220) and I'd like to have some broader discussion of the problem. In this bug CVP correctly marks an add as nuw basing on the loop latch check, but later loop rotation pass moves the add to a point before the check. In the new

On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: > On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > In the current mangling scheme for overloaded intrinsics we include > > overloaded type names in the intrinsic name. For example: > > > > %struct.foobar = type { i32 }...

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: