search for: pichet

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chad Rosier" <mcrosier at codeaurora.org>, "Jakob Stoklund Olesen" <jolesen at apple.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc....

The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win! thanks, Adrian > On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > In retrospect I totally agree with you. I am looking at LiveDebugValue again to see if I can improve certain specific cases. > > On Wed, May 11, 2016 at 5:14 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> w...

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Francois Pichet" <pichet2000 at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:45:53 PM > Subject: Re: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > ----- Original Message ----- > &gt...

> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc&q...

...nly. On my system, vector registers are more likely to be used on leaf functions anyway. On Thu, Nov 21, 2013 at 3:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Hal Finkel" <hfinkel at anl.gov> > > To: "Francois Pichet" <pichet2000 at gmail.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Monday, November 18, 2013 2:45:53 PM > > Subject: Re: [LLVMdev] Unaligned load/store for callee-saved 128-bit > registers > > > > ----- Or...

> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Good point. > > Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize this might be wrong in some (corner?) cases where vreg0 no longer refer to "x" > > My fix would be to propagate the DEBUG_VA...

...cause StackAlign is 4. Adding a check for stack realignable or putting all the 128-bit registers as caller-save will fix the problem. if (!TFI->isStackRealignable()) <--- new line Align = std::min(Align, StackAlign); Is this a bug or am I missing something? Thanks, Francois Pichet, Octasic. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131118/dc1987a8/attachment.html>

----- Original Message ----- > From: "Francois Pichet" <pichet2000 at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 18, 2013 2:26:30 PM > Subject: [LLVMdev] Unaligned load/store for callee-saved 128-bit registers > > > > On my (out-of-tree) target I...

...they are > issued with nothing affecting the carry in between in the first place). > Therefore, you shouldn’t have to force them to be stuck together. > > If you still do, what Jakob proposed is what you are looking for. > > -Quentin > > On Apr 15, 2013, at 2:02 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hi, > > Let's say we have a 32-bit architecture where 64-bit additions are done > using 2 operations. > > Instructions are defined as follow in TableGen: > defm ADD64 : ALU32<"add", 1, 1, addc>; > defm...

...ng a pseudo instruction seems the best approach for you. For instance, you can match your add64 during isel with your pseudo instruction and expand it just before emitting the assembly file (add a pass using the hook: addPreEmitPass on your target). -Quentin On Apr 15, 2013, at 2:37 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > I really have to force them to stuck together otherwise the carry will just not work. > > How about wrapping the 2 instructions in a bundle? > Would that be a way? > http://llvm.org/docs/CodeGenerator.html#machineinstr-bundles > &g...

> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main...

On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE,...

On Mon, Aug 5, 2013 at 2:25 PM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > > On my target store/load of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach (to simplify > things) : > > >...

On Mon, Feb 23, 2015 at 2:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Francois Pichet" <pichet2000 at gmail.com> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Sunday, February 22, 2015 5:34:11 PM > > Subject: [LLVMdev] Question about shouldMergeGEPs in InstructionCombining > > > > Hello > > &g...

Hi, Let's say we have a 32-bit architecture where 64-bit additions are done using 2 operations. Instructions are defined as follow in TableGen: defm ADD64 : ALU32<"add", 1, 1, addc>; defm ADD64C : ALU32<"addrc", 1, 2, adde>; Let's assume that the carry bit is implicit and that the 2 operations must *always* be stuck together for the 64-bit add to

...llZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false; Following that change, I noticed some performance gain for a few specific tests and no regression at all in our (admittedly limited) benchmarks suite. Regards, Francois Pichet, Octasic. On Thu, Mar 12, 2015 at 4:14 PM, Mark Heffernan <meheff at google.com> wrote: > Coincidentally, I just ran into this same issue on some of our benchmarks > for the NVPTX backend. You have something like this before instcombine: > > %tmp = getelementptr inbounds i32,...

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Francois Pichet" <pichet2000 at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "chandlerc" <chandlerc at gmail.com> > Sent: Tuesday, February 24, 2015 11:27:43 PM > Subject: Re: [LLVMdev] Question about shouldMergeGEPs in InstructionCom...

What is the proper solution to disable auto-vectorization for unaligned data? I have an out of tree target and I added this: bool OpusTargetLowering::allowsUnalignedMemoryAccesses(EVT VT, bool *Fast) const { if (VT.isVector()) return false; .... } After that, I could see that vectorization is still done on unaligned data except that llvm will copy the data back and forth from the source

...mit vectorization to 16-byte aligned 128-bit data then? All the memory copying done by ExpandUnalignedStore/ExpandUnalignedLoad is just too expensive. On Sat, Jul 20, 2013 at 12:52 PM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > > On Jul 19, 2013, at 3:14 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > > > > What is the proper solution to disable auto-vectorization for unaligned > data? > > > > I have an out of tree target and I added this: > > > > bool OpusTargetLowering::allowsUnalignedMemoryAccesses(EVT VT, bo...

Is anybody using the LLVM/clang/lldb compiled with the MSVC 2019 (x86-32bit) successfully? I am getting crash in SmallVector at multiple places after a llvm:SmallVector is being moved around in move constructor or move operator=. Not sure what is going on. ~SmallVectorImpl() { if (!this->isSmall()) free(this->begin()); // <=== crash here, line 336 SmallVector.h } The