similar to: [LLVMdev] Few questions about stack frame and calling conventions implementation in a backend

Hi all Ups, I'm really sorry for that previous message, I've sent it by mistake. So let me write it once more. I've been working for some time now on a backend for our CPU. However I couldn't figure out how to implement some stuff. I'd appreciate your help with these. First thing is return address saving. To do that, first I have to copy it to a general purpose register. I

On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > So let me write it once more. > > I've been working for some time now on a backend for our CPU. However I > couldn't figure out how to implement some stuff. > I'd appreciate your help

Hi Andrew, thanks for answering On Thu, Apr 15, 2010 at 3:35 PM, Andrew Lenharth <andrewl at lenharth.org>wrote: > On Thu, Apr 15, 2010 at 3:40 AM, Artur Pietrek <pietreka at gmail.com> wrote: > > Hi all > > Ups, I'm really sorry for that previous message, I've sent it by mistake. > > > > So let me write it once more. > > > > I've

I updated DwarfDebug to use section offset, instead of hard coding 0, to handle LTO properly. r107202. Thanks for brining this up. - Devang On Tue, Jun 29, 2010 at 11:27 AM, Devang Patel <devang.patel at gmail.com> wrote: > DW_AT_stmt_list attribute's value is a section offset to the line no > info for current compilation unit. If there is only one  compilation > unit

On Fri, Aug 21, 2009 at 12:33 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com> wrote: > > Hi All, > > Since few days I observe weird change. > > Consider the following C code > > > > char array[] = "0123456789"; > > extern int test(char arr[], int size); > >

Hi all, While implementing debug info for our backend, we've noticed a problem with debug_line section. We believe that the following code is wrong: // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. It is always zero when only one // compile unit is emitted in one object file. addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4,

Hi All, Since few days I observe weird change. Consider the following C code char array[] = "0123456789"; extern int test(char arr[], int size); int main(void) { return test(array-1, sizeof(array)-1); } using clang frontend i get this: %call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0, i32 -1), i32 10) ; <i32> [#uses=1] and using LLVM-GCC this: %1 =

DW_AT_stmt_list attribute's value is a section offset to the line no info for current compilation unit. If there is only one compilation unit generated per .o file then it is always zero. What kind of errors are you seeing ? - Devang On Tue, Jun 29, 2010 at 9:02 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all, > While implementing debug info for our backend, we've

Hi Devang, Thanks for working on that. Unfortunately after your change it still doesn't work (I've tried x86 and our backend under Linux). The problem is that you put difference between two labels .Lset7 = .Lsection_line_begin-.Lsection_line ## DW_AT_stmt_list and that will be evaluated by assembler to a constant. It has to be a label, not a constant, because it is the linker who knows

Hi all, while I was playing a little bit with IRBuilder I ended up with something like this when included NoFolder.h /work/llvm/include/llvm/User.h: In member function ‘llvm::Value* llvm::NoFolder::CreateExtractElement(llvm::Constant*, llvm::Constant*) const’: /work/llvm/include/llvm/User.h:48: error: ‘static void* llvm::User::operator new(size_t)’ is private

On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com> wrote: > Hi All, > Since few days I observe weird change. > Consider the following C code > > char array[] = "0123456789"; > extern int test(char arr[], int size); > > int main(void) { >   return test(array-1, sizeof(array)-1); > } > > using clang frontend i get this: > >

> -----Original Message----- > From: mbraun at apple.com [mailto:mbraun at apple.com] > Sent: Friday, February 17, 2017 3:15 PM > To: Alex Bradbury > Cc: llvm-dev; Adrian Prantl; Eric Christopher; Robinson, Paul > Subject: Re: [llvm-dev] RFC: Setting MachineInstr flags through > storeRegToStackSlot > > Can someone familiar with debug info comment on whether it matters

On Wed, Jun 30, 2010 at 1:57 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi Devang, > Thanks for working on that. Unfortunately after your change it still doesn't > work (I've tried x86 and our backend under Linux). What errors exactly you are seeing ? > The problem is that you put difference between two labels > .Lset7 = .Lsection_line_begin-.Lsection_line ##

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

Hi,Could someone explain to me how the sign/zero extensions in LLVM work, please? If I understood correctly, the int type in LLVM doesn't keep the information about signedness of an int. So the question is how can I know if instructions like Load or Trunc should be signed or not? I guess that at least ARM backend produces sign extended load so if someone could point me to the code where it

Hi All, When seeing the title "Prolog/Epilog Code Insertion", I'd expect something about XXXFrameLowering.cpp (particular about emitPrologue/emitEpilogue). But the document [1] is about unwind. Is it placed at the right place/section? Thanks. [1] http://llvm.org/docs/CodeGenerator.html#prolog-epilog-code-insertion Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage:

Hello, I want to find information/documentation on how reorganize stack frame (add other information, etc.) & how add new calling convention into ARM backend? I think it is needed to modify lowering of CALL, RET & FORMAL_ARGUMENT instruction, and also to modify emitPrologue & emitEpilogue functions. What are the others things to modify in order to realize my

Hi list, I am trying to implement the technique outlined in the following paper: http://www.cs.umd.edu/~mwh/papers/martin10ownership.html in LLVM. My approach so far involves the use of an IR level transform (via runOnFunction) to identify memory loads and stores. One thing I need to do (I am pretty sure I need to do it at least) is automatically mark each stack frame as "owned" by the

Hi, In the runtime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI,

On Aug 27, 2010, at 11:00 AMPDT, Eric Christopher wrote: >>> >>> For some reason I am getting this error even when I only have an >>> empty 'main' function. So I couldn't create .ll file reproducing >>> it and I have to debug myself. >>> >>> The function causing the problem is stub created in >>> JIT::runFunction: