similar to: [LLVMdev] Out of tree targets: API Change to MFI::CreateStackObject

Dear all, I would like to share a paper I co-authored with Prof. Alper Sen. This paper describes an algorithm to generate testbenches from SystemC models represented with LLVM IR. It was accepted and presented at International Conference on Hardware/Software Codesign and System Synthesis (CODES/ISSS), 2012. A link to the paper is accessible from acm or Alper's website:

On Sep 11, 2009, at 3:31 PM, David Greene wrote: > Attached is a patch to print asm comments for spill information. > We've discussed the mechanisms before but I wanted to run the > patch by everyone before I start to commit pieces. Some thoughts: The general approach to enhancing CreateStackObject and adding MachineInstr::AsmPrinterFlags seems fine to me! The testcase should

On Monday 14 September 2009 12:32, Chris Lattner wrote: > On Sep 11, 2009, at 3:31 PM, David Greene wrote: > > Attached is a patch to print asm comments for spill information. > > We've discussed the mechanisms before but I wanted to run the > > patch by everyone before I start to commit pieces. > > Some thoughts: > > The general approach to enhancing

Hello, after some time I'm trying to build my code with the current CVS of LLVM, and have a problem. The mentioned file, around line 184, contains: if (FixedSlot == FixedSpillSlots+NumFixedSpillSlots) { // Nope, just spill it anywhere convenient. FrameIdx = FFI->CreateStackObject(RegInfo->getSpillSize(Reg)/8,

Very interesting, thanks for the forward! If you're interested in having a link posted on llvm.org, please email the llvmdev mailing list. -Chris On Jan 30, 2013, at 9:42 AM, Marcelo Sousa <marceloabsousa at gmail.com> wrote: > Dear all, > > I would like to share a paper I co-authored with Prof. Alper Sen. This > paper describes an algorithm to generate testbenches from

The following problems happens with architectures, where stack alignment is smaller than the biggest preferred alignment for any data type SP pointer may point anywhere with alignment of stack alignment (4 in our case) SelectionDAGBuilder however calls CreateStackObject with preferred alignment is given data type(8 in our problemaric case. The ABI alignment for this data type is only 4) This

Vladimir Prus wrote: > What's the division by 8 for? Neither 'CreateStackObject' nor > 'getSpillAlignment' documentation say what units the size is, but > everywhere it's in bytes. In my specific case, 'getSplillAlignment' returns > 4, which becomes 0 after division. Oh, it looks that backends now should specify register size in bits. I've updated

Hello, I plan to implement "Stack Smashing Protection - Strong" support in LLVM. Below is a description of this feature and an overview of the implementation plan. I have divided up the implementation into stages that can be delivered incrementally. I'm looking for any feedback (suggestions, requests, etc) before I actually begin the work. Thank you! Josh

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

Hi llvmdev, I'm trying to figure how llvm remembers stack slots allotted to callee saved registers on x86. In particular, llvm pushes registers in decreasing order of FrameIdxs [1], so the offsets they get (as returned by MFI->getObjectOffset) don't directly correspond to their actual stack locations. In X86FrameLowering's emitCalleeSavedFrameMoves, when emitting DWARF

----- 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 registers. >

I'm working on a target for the intermediate language of another compiler (so it can benifit from LLVM's optimization stages). I'm working on LLVM 3.1 for now. I started the translater as a copy of the MIPS target so that I can just modify it to produce the correct output. I basically want to replace all of the local variables and incoming parameters with values that look like this:

If you're running a MachineFunctionPass, then the code has already been lowered to machine instructions and modifying the original IR will most likely not do what you want. You should only be using the IR as an immutable object for reference. If you want to change the IR, I would suggest using a FunctionPass instead of a MachineFunctionPass. Unless you need codegen data. At the

----- 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

BTW I managed to get around this problem by flagging all the 128-bit registers as caller saved only. 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

CRAN (and crantastic) updates this week New packages ------------ * DCGL (1.0) Bao-Hong Liu http://crantastic.org/packages/DCGL Functions for basic differential coexpression analyses: gene filtering, link filtering, DCG (Differentially-Coexpressed Gene) identification and DCL (Differentially-Coexpressed Links) identification.Two algorithms,named DCP and DCe, are provided for

On 31.5.2014 2:04, Pasi Parviainen wrote: > On 28.5.2014 2:57, Sanjoy Das wrote: >> Hi llvmdev, >> >> I'm trying to figure how llvm remembers stack slots allotted to callee >> saved registers on x86. In particular, llvm pushes registers in >> decreasing order of FrameIdxs [1], so the offsets they get (as >> returned by MFI->getObjectOffset) don't

Can you tell us a bit more about what you're trying to accomplish? Changes to the IR performed during MachineFunctionPass::doInitialization will likely propagate down through code generation, but at that point what is the purpose of using a MachineFunctionPass? You won't have any analysis or instruction information available until runOnMachineFunction. On Mon, Aug 5, 2013 at 12:00 PM,

Micah, Thanks for your help. I will study on that code. Justin, Sorry for my misleading word. Local memory in OpenCL is the same as share memory in CUDA. What I mean is share memory, so MachineFrameInfo is not suitable to me. And I need codegen data, so FunctionPass is also not suitable. Anyway, thanks for the suggestion. Antony 2013/8/5 Justin Holewinski <justin.holewinski at

Hi folks; I have acquired a rackmount Intel server with a RAID card in it that appears to be compatable with the MFI driver. To put it mildly, this thing SMOKES! It is SCREAMING fast. Insane, in fact. Ok, enough supurlatives. Now the question is this - exactly what board(s) will this driver support? Is it only the two that are listed in the hardware release notes? LSI has a number of