similar to: [LLVMdev] handleMoveIntoBundle assertion

Hi again, Just forgot to add PATCH prefix to my message! Could you please review it ? Ivan Le 26/05/2012 00:52, Ivan Llopard a écrit : > Hi, > > I have a custom scheduler/bundler running just after coalescing as > proposed by the current infrastructure of machine schedulers. Btw, > great thanks for this cool stuff ! > I'm running into problems when I want to update the

Hi Ivan, I'm just looking into it now. Thanks for working on this. - Lang. On Tue, May 29, 2012 at 6:50 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi again, > > Just forgot to add PATCH prefix to my message! Could you please review it ? > > Ivan > > Le 26/05/2012 00:52, Ivan Llopard a écrit : > > Hi, > > > > I have a custom

Patch looks good. Committed in r157632. Thanks Ivan! - Lang. On Tue, May 29, 2012 at 11:00 AM, Lang Hames <lhames at gmail.com> wrote: > Hi Ivan, > > I'm just looking into it now. Thanks for working on this. > > - Lang. > > > On Tue, May 29, 2012 at 6:50 AM, Ivan Llopard <ivanllopard at gmail.com>wrote: > >> Hi again, >> >> Just

Hi all, Thanks for your feed-backs :-) @Andrew: In fact, I've reused most of the postRA list scheduler code and the resource priority queue. Every time it needs to move forward, either because of a res hazard (HazardRec) or an invalid combination of instructions in the current packet (DFA), it closes the current bundle and advances to the next cycle. The non-interlocked nature of our

Hi, I'm working on a custom top-down post RA scheduler which builds bundles at the same time for our VLIW processor. I've borrowed most of the implementation from the resource priority queue implemented for the existent VLIW scheduler but applied to the context of MI scheduling. Basically, instructions that are likely to be bundled must be scheduled first (i.e. get higher priority).

On Jul 31, 2012, at 8:37 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > I'm working on a custom top-down post RA scheduler which builds bundles > at the same time for our VLIW processor. I've borrowed most of the > implementation from the resource priority queue implemented for the > existent VLIW scheduler but applied to the context of MI

Hi all, Tuning my TargetAsmPrinter implementation in the back-end side, I discovered that the address space number is not passed down while emitting global variables with constant initializers. The information is dropped at AsmPrinter::EmitGlobalConstant() function call which defaults it to zero. I would like to emit target-dependent asm directives depending on the address space of constant

Hi Eli, On 07/05/2012 18:15, Eli Friedman wrote: > On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi all, >> >> Tuning my TargetAsmPrinter implementation in the back-end side, I >> discovered that the address space number is not passed down while >> emitting global variables with constant initializers. The information is

Dave, Thank you for your interest. Please see my replies below. Sorry that my terminology is not as crisp as Andy's, but I think you can see what I mean. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: dag at cray.com [mailto:dag at cray.com] > Sent: Friday, May 11, 2012 12:14 PM > To: Sergei Larin > Cc:

Hi Eli, Thanks for your response. Please see my responses below. On 10/12/2011 00:28, Eli Friedman wrote: > On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at gmail.com> wrote: >> Hi all, >> >> I am writing a back-end for a processor that has complex type registers. >> It has two functional units to perform complex multiplications. >> From clang,

Le 07/05/2012 17:15, Joerg Sonnenberger a écrit : > On Mon, May 07, 2012 at 05:15:59PM +0200, Ivan Llopard wrote: >> Thanks for your quick response Joerg. >> >> We have a very small test case where there is global array and its >> address space attribute specified like in the following code >> >> const int __attribute__((address_space(256))) fangle[13] =

Hi, I'm writing a function pass which is dynamically loaded by opt and I need some analysis and passes to be run before my pass: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addPreservedID(LoopSimplifyID);

Hi, We've a target which has hardware support for zero-overhead loops. Currently, we cannot detect them because the loop unroller is unrolling them before entering into the codegen. Looking at its implementation, it seems that it checks if it is profitable to unroll it or not based on certain parameters. Given that zero cost loops building is based more or less on the same constraints

On Tue, May 8, 2012 at 4:59 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Eli, > > > On 07/05/2012 18:15, Eli Friedman wrote: >> >> On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> >>  wrote: >>> >>> Hi all, >>> >>> Tuning my TargetAsmPrinter implementation in the back-end side, I

Hi Anshu, I don't have commit access. It applies correctly on trunk, I've just checked it. Could you please commit it? Ivan On 26/06/2012 04:44, adasgupt at codeaurora.org wrote: > Hi Ivan, > > Sorry, I should have been more explicit in my last email. The patch looks > good to me. Please check that it applies on trunk and go ahead and commit. > > Thanks > -Anshu

Thanks for helping explain the infrastructure. One ammendment... On May 11, 2012, at 11:28 AM, Sergei Larin <slarin at codeaurora.org> wrote: > [Larin, Sergei] Kind of. Once bundles are finalized, bundle header become a > new "super instructions", and if a pass does not need to look at individual > (MI) instructions, there will not be any difference for it. But if a pass

Hi again, I come back to this issue with an example. It's a pass which does nothing but throw the 'Unable to schedule' error. namespace { struct MyPass : public FunctionPass { static char ID; // Pass identification, replacement for typeid MyPass() : FunctionPass(ID) { initializeMyPassPass(*PassRegistry::getPassRegistry()); } virtual void

Hi Hal, On 21/11/2012 22:38, Hal Finkel wrote: > ----- Original Message ----- >> From: "Ivan Llopard" <ivanllopard at gmail.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Wednesday, November 21, 2012 10:31:07 AM >> Subject: [LLVMdev] Disable loop unroll pass >> >> Hi, >> >> We've a

On Fri, 23 Mar 2012 09:50:12 +0100 Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Finkel, > > Le 23/03/2012 05:50, Hal Finkel a écrit : > > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > > currently has a problem handling integer types smaller than 64 bits. > > This is because the ABI specifies that these types are > > zero-extended

Hi, I've refactored the DFA generator in TableGen because it takes too much time to build the table of our BE and I'd like to share it. We have 15 functional units and 13 different itineraries which, in the worst case, can produce 13! states. Fortunately, many of those states are reused :-) but it still takes up to 11min to build the entire table. This patch reduces the build time to