search for: pichet2000

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>> wrote: > &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", <!18&g...

> 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_VALUE only if &qu...

----- 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.edu> > Sent: Th...

...t; 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 ADD64C : ALU32&...

...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 > > > On Mon...

> 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 problem. > 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 ----- > > From: "Francoi...

..., 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 > > > > ----- Original Message -----...

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 > > > > I am not sure...

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

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

----- 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 have 16 128-bit regis...

...zation 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, bool > *Fast)...

Thanks for response Francois . Do you have any pointers on what can be the issue here or something I can try out. I saw similar active bug in llvm database https://llvm.org/bugs/show_bug.cgi?id=5623 Thanks Ashish On Thu, Mar 26, 2015 at 10:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > > On Wed, Mar 25, 2015 at 4:47 PM, Ashish Saxena <ashishcseitbhu at gmail.com> > wrote: > >> Hi , >> I am trying to enable link time optimization for my projects. Few of >> them has inline assembly which works perfectly with cl...

On my (out-of-tree) target I have 16 128-bit registers. Unaligned load/store are illegal. (must 16-bytes aligned) 8 of those registers are defined as callee-saved and 8 caller-saved. The default stack size is 4 bytes. The target implements dynamic stack realign to make sure the stack will always be aligned correctly when necessary. Yet I am still getting unaligned load/store when running this

On Thu, Oct 14, 2010 at 4:09 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Francois, > >> In that case, RTTI and exception should also be disabled from CMake >> generated projects right? >> Currently they are enabled all over my MSVC projects. > > I'm not sure what you are asking.  The goal is for LLVM to not require > RTTI or exception handling.

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 ADD64C : ALU32<&quo...

----- 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 InstructionCombining > > w--...

...t; vectorized code -> ... -> instcombine (calls ComputeMaskedBits) which computes better alignment for pointer accesses like “aligned_ptr += 128bit”. I will have to work on this soon as ARM also has pretty inefficient unaligned vector loads. On Jul 21, 2013, at 9:29 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > Ok any quick workaround to limit 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 <asc...