similar to: [LLVMdev] Build warning on TOT

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 Aug 31, 2010, at 6:08 PM, Dale Johannesen wrote: > 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..................... >

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 X86RegisterInfo.cpp. I'm wonder what's their purpose? They're filling up my symbol table... Cameron Esfahani

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:

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

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

Any ideas? Instruction uses an alias of an allocated register UNREACHABLE executed at RegAllocFast.cpp:358! 0 clang 0x0000000101309bc2 PrintStackTrace(void*) + 34 1 clang 0x000000010130a863 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff8056935a _sigtramp + 26 3 libSystem.B.dylib 000000000000000000 _sigtramp + 2141809856 4 clang 0x00000001012dd96d

Dear all, I would like to compare two distance matrices to find the correlation between those and create a XY plot.could you please kindly help me and let me know how I can do that using R.(Mantel test?). Your help is very much appreciated!! Many thanks! Regards, Sima Fakheran ............................................................... Sima Fakheran Esfahani PhD Student Institute of

Good afternoon! I would like to ask you about similarity measures and clustering in R for Binary data. Would you please kindly help me and let me know about that commands in R? Thanks in advance for your kind attentions. I look forward to hearing from you as soon as possible. Best regards, Sima

Thomas B. Ruecker, DM8TBR wrote: >Hi Gilles, > > > >>Well, it's not my native language so I'm not pretty sure of my english. :) >> >> >My neither. Hey this is a multinational community. ;) > > > Yeah, that's right. >>Did somebody try the xsls ? >> >> >yup. >Tried your xlst-files for the stats. Noticed some

> There isn't one at the moment, ideally it should figure it out, but I haven't looked much into it - it may be that this isn't working yet. I should say that I'm still a bit confused: Is it possible to build for ARM CPUs now? 1/ from which hosts (x86-*-* ?) 2/ for which targets (arm-*-* ?) 3/ what are the supported tools for ARM targets: a/ llvm-gcc (gcc 4.2)?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Pascoe wrote: |Speaking of which, is there a way to view (via the XSL interface) the |source information (IP address, source software)? | |Dave If this information is included in the xml stream, then this is easy, but I'm actually not sure of the presence of this information. I'll have a look later (when my computers will have finished

On Mon, Aug 30, 2010 at 5:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 21, 2010, at 5:27 PM, Eli Friedman wrote: > >> See http://llvm.org/bugs/show_bug.cgi?id=4668 and >> http://llvm.org/bugs/show_bug.cgi?id=5010.  The basic description of >> the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The >> fundamental problem

On Nov 17, 2010, at 11:14 PM, Duncan Sands wrote: > Hi Evan, > >> Thanks David. Unfortunately many of us cannot use GPL v3 gcc so it's hard for us >> to investigate this. One question, can you tell if gcc is inlining significantly >> more than llvm? We have reports that this is one of the issue plaguing eon >> performance. > > are you allowed to look at

Hi Evan, > Thanks David. Unfortunately many of us cannot use GPL v3 gcc so it's hard for us > to investigate this. One question, can you tell if gcc is inlining significantly > more than llvm? We have reports that this is one of the issue plaguing eon > performance. are you allowed to look at assembler output by GPL v3 gcc? If so, maybe someone else can do the compiling for you,

Thanks David. Unfortunately many of us cannot use GPL v3 gcc so it's hard for us to investigate this. One question, can you tell if gcc is inlining significantly more than llvm? We have reports that this is one of the issue plaguing eon performance. There are also some relatively well known spec optimizations that we haven't implemented. e.g.

Hi, I have looked at the LLVM code generation quality using small test cases and in general it is better than I thought and in some cases better than gcc. However, there are still some gap in SPEC performance. I have not looked at the root cause of those gaps. Anyone who cares about LLVM performance need to take this seriously. For fair comparison, I used -fno-strict-aliasing in gcc to turn off