similar to: [LLVMdev] Purpose of PROLOG_LABEL in function prologue?

On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: > > _main: > pushq %rbp > Ltmp18: > movq %rsp, %rbp > Ltmp19: > subq $320, %rsp > Ltmp20: > movl %ecx, -276(%rbp) > > I've tracked them back to emitPrologue in

On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18: >> movq %rsp, %rbp >> Ltmp19: >> subq $320, %rsp >>

I don't see any references to them, that's why I brought it up... On Aug 3, 2010, at 3:12 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:04 PM, Cameron Esfahani wrote: > >> I've been building/dumping some x86_64 code and I've noticed that each of the routines has 3 temporary symbols, à la: >> >> _main: >> pushq %rbp >> Ltmp18:

Hi, I have run into the following strange behavior and wanted to ask for some advice. For the C program below, function sum() gets inlined in foo() but the code generated looks very suboptimal (the code is an extract from a larger program). Below I show the 32-bit x86 assembly as produced by the demo page on the llvm home page ("Output A"). As you can see from the assembly, after

I don't know much about this, but maybe -mllvm -unroll-count=1 can be used as a workaround? /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Brent Walker Sent: den 28 mars 2012 03:18 To: llvmdev Subject: [LLVMdev] Suboptimal code due to excessive spilling Hi, I have run into the following strange behavior

Is there any reason why we couldn't skip emitting temporary labels in the COFF writer? I tried that and everything looks okay... On Aug 3, 2010, at 3:21 PM, Eric Christopher wrote: > > On Aug 3, 2010, at 3:19 PM, Cameron Esfahani wrote: > >> I don't see any references to them, that's why I brought it up... > > Interesting. Is this COFF? We may not emit the

On Aug 3, 2010, at 3:19 PM, Cameron Esfahani wrote: > I don't see any references to them, that's why I brought it up... Interesting. Is this COFF? We may not emit the final debug info, but leave the ranges in. If they're filling up your symbol table then we likely need another type of assembler label for "COFF internal". -eric

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

If I read the llvm language correctly, it doesn't have a way to specify the preferred branch, correct ? I see nothing in the specs for "branch" or "switch". And __buildin_expect does nothing, that I am sure of. Unfortunately llvm has this knack for ordering my one most crucial part of code exactly the opposite I want to, it does: (x86_64) cmpq %r15, (%rax,%rdx) jne

On 08/27/2010 11:32, Yuri wrote: > As I understand only one of TCRETURNri64 and RET should be created. > I have sources of rev.112200. > > Here is the stack when TCRETURNri64 instruction is created: > #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr > (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}, > NoImp=false) at

Anyone seeing the following: llvm[3]: Compiling SelectionDAGISel.cpp for Release+Asserts build Decoding Conflict: ____0001111_........________.... ____0001111_.................... ____0001111..................... ____0001..1..................... ____0001........................ ____00.......................... ____............................ ................................

include/llvm/Support/FileSystem.h has file_type which enumerates the file system’s view of the file type. One of the values is “symlink_file”. But because the Unix implementation of status() calls stat() instead of lstat(), if the path refers to a symbolic link, the link is followed. There’s no way to get information about the symbolic link itself. I think changing status() to call lstat() is

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:

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

Yes, and it's a recent regression. Building without -j shows where it really is: llvm[3]: Building ARM.td decoder tables with tblgen Decoding Conflict: ____0001111_........________.... ____0001111_.................... ____0001111..................... ____0001..1..................... ____0001........................ ____00..........................

On Thu, Jul 23, 2009 at 4:06 PM, Joshua Moore-Oliva<llvm-dev at chatgris.com> wrote: > If I could reduce my requirements to the ability to the following: >    * Ability to know how much stack space a function requires >    * Move the stack pointer arbitrarily (the ability to write my own function > prologue and epilogue, would need to be able to insert assembly/low level >

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

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

First off, thanks for the help so far. >From what I have been able to tell, emitPrologue kicks in after the arguments for the function have been copied. For example, consider the function int testfunc( int foo, int bar ); Emitting assembly code from the llvm-gcc frontend in a small test program gives the following for the call to testfunc movl $1338, (%esp) movl $1339, 4(%esp) call

I probably should've used boolean terms in addition to numeric values when indexing, but currently I have a set of numeric values[1] and trying to avoid having to reindex ~250GB DBs (and asking numerous users to do the same). Say I have a bunch of values which I want to filter a query against. If I had boolean terms, it could just OP_OR against the whole set. IOW, this is what notmuch does