search for: quentins

I’d like to nominate Quentin Colombet as LSR code owner. He has handled most of the reviews for me for the past couple years (thanks Quentin), and is willing to take on the responsiblity. Frankly, turning over ownership to Quentin is overdue. -Andy

> On Nov 17, 2016, at 8:51 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I’d like to nominate Quentin Colombet as LSR code owner. He has handled most of the reviews for me for the past couple years (thanks Quentin), and is willing to take on the responsiblity. Frankly, turning over ownership to Quentin is overdue. This also seems pretty obvious to me, and

Thanks Diana. That is indeed the assumption in the code and this is obviously wrong. Could you try the attached patch? (I haven’t even tried to compile it though) Cheers, -Quentin -------------- next part -------------- A non-text attachment was scrubbed... Name: localizer_tentative_fix.diff Type: application/octet-stream Size: 774 bytes Desc: not available URL:

Hi Jonas, I won’t have time to look at it this week after all. I’ll try to do that next week. If you do not hear back from me by end of next, do not hesitate to ping me! Cheers, -Quentin > On Apr 22, 2015, at 9:32 AM, Quentin Colombet <qcolombet at apple.com> wrote: > >> >> On Apr 21, 2015, at 11:49 PM, Jonas Paulsson <jonas.paulsson at ericsson.com

Cool test :) It seems to work fine now, I don't see any new failures. IIUC, Kristof is also giving it another run. Cheers, Diana On 30 May 2017 at 22:57, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > > I’ve actually gone ahead and pushed the fix as I was able to produce a > small reproducer. > > This is r304244 > > Let me know if you encounter

Thanks Quentin, it's in progress now, I'll let you know how it goes. Cheers, Diana On 27 May 2017 at 03:36, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Kristof, > > I’ve pushed the localizer in r304051 and added it in the AArch64 O0 pipeline > in r304052. > > I let Diana investigate the seg fault she was seeing. > > @Diana, let me know if you need

Hi, Shrink-wrapping capabilities, i.e., better placement of prologue and epilogue sequences, landed in r236507 but are not yet enabled by default. Since r236507 AArch64 is shrink-wrapping ready, meaning we can turn the pass on for this target. I’ve done the same for X86 in r 238293. Now, I need your help to test and benchmark how shrink-wrapping perform on those targets. The goal is to decide

On Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill flag of DstReg. Therefore, I still think, this is the

AddRegisterOperand calls getVR and yes, I think an IMPLICIT_DEF is being generated. On Tue, Aug 25, 2015 at 2:40 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > On Aug 25, 2015, at 11:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have not tried 3.5, it's a significant amount of work to port from one > version to the next though, I did not

Hi Ryan, > On Aug 24, 2015, at 6:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Quentin, > > I apologize for the spamming here but in getVR (where VReg is assigned an RC), it calls: > > const TargetRegisterClass *RC = TLI->getRegClassFor(Op.getSimpleValueType()); > VReg = MRI->createVirtualRegister(RC); > > My question is why is it using the

BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG <ga:@a+1>[TF=1]; GPRRegs:%vreg0 %vreg1<def> = COPY %vreg0; PTRRegs:%vreg1 GPRRegs:%vreg0 Send_iii %NULLR0, %vreg1<kill>, 1, 1, 1, 1, 0; PTRRegs:%vreg1 RetRA This is what I get. This is what I'd like to get: BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG

I have not tried 3.5, it's a significant amount of work to port from one version to the next though, I did not personally do the 3.4 to 3.6 porting. I agree though, it was very strange that it suddenly just changed behavior. It looks like to me that InstrEmitter.cpp:getVR is the one assigning the virtual register no? Though this code in CreateVirtualRegisters: const TargetRegisterClass *RC

On 18 May 2017 at 19:09, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > >> On May 18, 2017, at 1:15 AM, Diana Picus <diana.picus at linaro.org> wrote: >> >> On 18 May 2017 at 09:06, Kristof Beyls <Kristof.Beyls at arm.com> wrote: >>> I think Diana found that when enabling r299283, the bootstrap failed with >>> llvm-tblgen

Hi Quentin, I actually did a run with -mllvm -optimize-regalloc -mllvm -regalloc=greedy over the weekend and the test does pass with that. Haven't measured the compile time though. Cheers, Diana On 19 May 2017 at 19:06, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > > On May 19, 2017, at 1:33 AM, Diana Picus <diana.picus at linaro.org> wrote: > >

1. MOV16Copy_IMM_REG is the instruction matched, sorry. AD is the multiclass. The IMM in my case is a global. So you can see that GPRBaseRegs, GPRBaseRegs sets the registerclass for both the src and dst operands, in this case (MOV16Copy_IMM_REG) it's the dst. 2. Yes I agree, it most likely would. Honestly, this comes across like a bug, or unintended feature. It's adding an extra COPY to

Here is the instruction in question: multiclass AD<string asmstr, SDPatternOperator OpNode, RegisterClass srcAReg, RegisterClass dstReg, ValueType srcAType, ValueType dstType, Operand ImmOd, ImmLeaf imm_type> { def REG_REG : SetADInOut<asmstr, srcAReg, dstReg, [(set dstReg:$dstD, (OpNode srcAReg:$srcA))]>; def IMM_REG :

Quentin, It's in the instruction selection, sorry I forgot to mention that. The Vreg class is GPR and an extra COPY is generated to copy from the GPR to the Base Reg, even though my 'mov' instruction has Base in the Register class list. On Fri, Jul 31, 2015 at 12:50 PM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Ryan, > > Could you check where those moves

Quentin, This is the issue. Somewhere prior to the constrainRegClass, it's assigning the GPRBase sub class of GPR to the MOV instruction, so it can't constrain it to Base and hence has to add the COPY. Now I just need to find out why it is ignoring the TableGen defined GPRBase for the MOV MI in favor of it's sub class GPR. Thanks. On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor

On 07/25/2013 05:09 PM, Quentin Colombet wrote: > Hi, > > I think we have a consensus on how we should report diagnostics now. > For broader uses, the discussion is still open. > > To move forward on the diagnostic part, here is the plan: > - Extend the current handler with a prototype like: > void report(enum Kind, enum Classification, const char* msg) > where > -

On 18 May 2017 at 09:06, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > I think Diana found that when enabling r299283, the bootstrap failed with > llvm-tblgen segfaulting. > So there clearly is some work required there. Indeed. @Quentin, what is the status of that patch? Have you been working on it since then? Should I investigate the segfault more and send you a reproducer?