search for: mmaggioni

...backend I return CSR_RegMask in getCallPreservedMask and return CSR_SaveList in getCalleeSavedRegs. Is that a correct setup? I dumped the regmask and found that callee saved regs are marked 1 and non-callee saved regs are 0. Thanks, Xiaochu On Wed, Aug 26, 2015 at 5:58 PM Marcello Maggioni <mmaggioni at apple.com> wrote: > Is the preserved mask passed down to your Call instruction in LowerCall ? > > Marcello > > On 26 Aug 2015, at 17:52, Xiaochu Liu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Dear there, > > I was wondering how to preserve reg...

Probably the issue is solvable in some Codegen prepare pass. That said I still believe some kind of control on if we would like to implement this or not could be useful. Just a question. Why implementing it in SimplifyCFG and not as a separate pass like JumpThreading or something like that? The transformation itself doesn’t seem to fit much in SimplifyCFG. > On 2 Sep 2016, at 13:35, Michael

...possible for someone to add such a complementary comment ? > > > > > > Thanks, > > --Peter Lawrence. > > > > > > > > *From:* Craig Topper [mailto:craig.topper at gmail.com] > *Sent:* Wednesday, May 25, 2016 9:31 PM > *To:* Marcello Maggioni <mmaggioni at apple.com> > *Cc:* Lawrence, Peter <c_plawre at qca.qualcomm.com>; llvm-dev at lists.llvm.org > > *Subject:* Re: [llvm-dev] dumb question about tblgen > > > > The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with > a class for every type in Ma...

On Fri, Sep 29, 2017 at 8:02 PM, Marcello Maggioni <mmaggioni at apple.com> wrote: > I see the usecase for mixed language compilation (that’s probably why you fancy something like the side-effect thing instead right?) > That could be a reason, but it wasn't my main motivation. Basically I'm worried about having per-passes specific flags for...

...of the loads. Having a way to opt-out or control what you want to sink I still think would be a added value to the optimization. Marcello > On 2 Sep 2016, at 15:05, James Molloy <James.Molloy at arm.com> wrote: > > Hi, > >> On 2 Sep 2016, at 22:40, Marcello Maggioni <mmaggioni at apple.com <mailto:mmaggioni at apple.com>> wrote: >> >>> What the optimization is doing is extracting the “getelementptr” , making an instruction out of it, sinking the load and using a PHI to select between the address. >>> This breaks our selection of this typ...

> > Instead of adding the operands to a list, erase the instruction and add them to the worklist wouldn’t be probably faster something like: > > if (Instruction *Used = dyn_cast<Instruction>(*OI)) > if (Used->hasOneUse()) > WorkList.insert(Used); > > If it has one use is going to be the instruction we are going to remove anyway, right? I don’t think this

...th “MahineValueType.h”, but there is no such comment in “MachineValueType.h”, Would it be possible for someone to add such a complementary comment ? Thanks, --Peter Lawrence. From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Wednesday, May 25, 2016 9:31 PM To: Marcello Maggioni <mmaggioni at apple.com> Cc: Lawrence, Peter <c_plawre at qca.qualcomm.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] dumb question about tblgen The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with a class for every type in MachineValueTypes.h On Wed, May 25, 2016 at...

Dear there, I was wondering how to preserve registers (caller saved) across calls. I implemented getCalleeSavedRegs and getCallPreservedMask. But the non-callee-saved registers are still not saved by caller. I want to spill these registers in use on stack right before the call. From my understanding, the register allocator in llvm will do the spill and restoring automatically? Is there anything I

I see the usecase for mixed language compilation (that’s probably why you fancy something like the side-effect thing instead right?) BTW if the other proposal passes can we basically assume that if a loop doesn’t have the sideeffect intrinsic in it is then removable? That patch seems to suggest that in its current state llvm is mostly broken for languages that consider all infinite loops as

I don’t quite follow why you are doing something like this. What is the advantage of this instead of just attaching the AddrRegs regsister class as the register class for your instruction? So that you would have an ADD instruction like %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 What kind of problematic regalloc are you trying to avoid with introducing a new backend data type? Marcello > On

The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with a class for every type in MachineValueTypes.h On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don’t quite follow why you are doing something like this. > > What is the advantage of this instead of just attaching the AddrRegs > regsister class as the

Quentin, My real problem is that my target has separate address and data registers. The way I’d like to try getting better reg-alloc than I am now is to bring out the difference as Early as possible, so I have added p16, p32, p64 to the enum in “MachineValueType.h” And I have called addRegisterClass(MVT::p32, &XyzAddrRegsRegClass); And I have an override for virtual

On 2 Sep 2015, at 02:54, Joseph Tremoulet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Reading further, I see both that addrspacecast "can be a no-op cast or a complex value modification"[2] and that bitcast "may only be [used on pointers] with the same address space"[4]. > > So I'm getting the impression that it's ok to have a model with

Thanks, this makes the use case much more clear. Now though, as far as I would like actually to see supported in LLVM the capability of not having any special meaning assigned to address space 0 your proposal goes slightly in contrast with how I always thought of address spaces in LLVM. I also have to say that I don’t know deeply how address spaces are meant to be intended in LLVM so my vision of

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote: