search for: 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: >> movq %rsp, %rbp >> Ltmp19: >> subq $320, %rsp >> Ltmp20: &...

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

...tines 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 dirty at apple.com "All that is necessary for the triumph of evil is that good men do nothing." Edmund Burke

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

...____0001111..................... ____0001..1..................... ____0001........................ ____00.......................... ____............................ ................................ MVNCCi ____0001111_____________________ MVNs ____0001111_____________________ Cameron Esfahani dirty at apple.com "All that is necessary for the triumph of evil is that good men do nothing."

...link. Or this is such an uncommon case, that it’s the caller’s responsibility to detect if a file path refers to a symbolic link in whatever platform appropriate mechanism they have available to them. If that’s the case, then I suggest removing symlink_file from file_type. Any comments? Cameron Esfahani dirty at apple.com "There are times in the life of a nation when the only place a decent man can find himself is in prison."

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

...00.......................... ____............................ ................................ MVNCCi ____0001111_____________________ MVNs ____0001111_____________________ llvm[3]: Building ARM.td enhanced disassembly information with tblgen On Aug 31, 2010, at 5:51 PMPDT, Cameron Esfahani wrote: > Anyone seeing the following: > > llvm[3]: Compiling SelectionDAGISel.cpp for Release+Asserts build > Decoding Conflict: > ____0001111_........________.... > ____0001111_.................... > ____0001111..................... > ____0001..1......................

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 >> Ltmp20: &...

...010004e3e9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393 17 clang 0x000000010001eef5 cc1_main(char const**, char const**, char const*, void*) + 2949 18 clang 0x0000000100025c24 main + 4740 19 clang 0x000000010001d048 start + 52 Cameron Esfahani dirty at apple.com "It is the spirit and not the form of law that keeps justice alive." Earl Warren

...with tblgen This is almost certainly bill's r 112664 patch. Bill, please take a look. If you need to pattern match something to MVN, you should define it in terms of a Pat<> pattern, not a new synonym for the same instruction. -Chris > > On Aug 31, 2010, at 5:51 PMPDT, Cameron Esfahani wrote: > >> Anyone seeing the following: >> >> llvm[3]: Compiling SelectionDAGISel.cpp for Release+Asserts build >> Decoding Conflict: >> ____0001111_........________.... >> ____0001111_.................... >> ____0001111..................... &gt...

...ind 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 Environmental Sciences University of Zurich Winterthurerstrasse 190 8057 Zurich Switzerland Tel: +41 1 635 61 18 Fax:+41 1 635 57 11 email:fakheran@uwinst.unizh.ch <http://www.uwinst.unizh.ch> www.uwinst.unizh.ch [[alternative HTML version deleted]]

...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 --------------------------------------------------------------------------------------------------------- Sima Fakheran Esfahani PhD Student Institute of Environmental Sciences University of Zurich Winterthurerstrasse 190 8057 Zurich Switzerland Tel: +41 1 635 61 18 Fax:+41 1 635 57 11 email:fakheran@uwinst.unizh.ch --------------------------------- [[alternative HTML version deleted]]

...or leaf functions. StackSize += 32; MFI->setStackSize(StackSize); } Why is it always allocating the register spill area? In a simple little test case, I was able to verify that, if that code was removed, the register parameters would properly get saved to their shadow space. Cameron Esfahani dirty at apple.com "Americans are very skilled at creating a custom meaning from something that's mass-produced." Ann Powers

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

...since Friday - does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 7:29 PM Subject: buildbot failure in LLVM on clang-cmake-thumbv7-a15-full-sh To: Adrian Prantl <aprantl at apple.com>, Cameron Esfahani <dirty at apple.com>, Chris Bieneman <beanz at apple.com>, David Blaikie <dblaikie at gmail.com>, Evgeniy Stepanov <eugeni.stepanov at gmail.com>, Matthias Braun < matze at braunis.de>, Reid Kleckner <rnk at google.com> Cc: gkistanova at gmail.com The Buildbot...

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