similar to: Program source is bigger after emission of reports

Estimados miembros de la lista, Estoy haciendo una análisis de supervivencia con R. Adjunto mis datos. Quiero analizar la supervivencia de 5 grupos diferentes y compararla. Para ello estoy utilizando el paquete survival. > s = Surv(c$tiempo, c$estado) > f = survfit(s ~ tratamiento, data = c) > d = survdiff(s ~ tratamiento, data = c) > d Call: survdiff(formula = s ~ tratamiento,

Hola, Manuel, No entiendo tu pregunta (la repito aqui para que sea mas explicito): hay alguna forma de comparar la probabilidad de supervivencias (en este caso anual) entre grupos sin utilizar un chi-cuadrado y un valor de P. Entiendo que lo que hace survdiff es comparar las curvas de supervivencia, pero yo quiero comparar la probabilidad de supervivencia entre grupos al final del estudio. Con

On 23/02/10 14:58, Richard Osborne wrote: > I've recently changed the XCore target to implement BR_JT as a jump to a > series jumps. The jump table entries are expand inline in the function > so there is no longer a need to emit jump tables at the end of the > function. However the emission of jump tables at the end of a function > is done inside the AsmPrinter base class and

I've recently changed the XCore target to implement BR_JT as a jump to a series jumps. The jump table entries are expand inline in the function so there is no longer a need to emit jump tables at the end of the function. However the emission of jump tables at the end of a function is done inside the AsmPrinter base class and there seems to be no way of disabling this. This also seems to

This new metadata format is currently optional. The old ptx_kernel calling convention should still work. The only thing you should have to change when converting from PTX -> NVPTX is the address space map. The calling conventions and intrinsics should be compatible with both. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]

With the following call: llvm::ExecutionEngine* engine; llvm::EngineBuilder builder( module ); builder.setEngineKind( llvm::EngineKind::Either ); // it will use JIT if available builder.setUseMCJIT ( true ); engine = builder.create(); These calls are successful in windows. But when I try in Linux (Ubuntu), the create() function fails with the error message: Target does not support MC emission

Hi everybody, I have noticed that the new NVPTX backend requires new metadata to identify the kernels in the module: define void @metadata_kernel(float* %a) { ret void } !nvvm.annotations = !{!1} !1 = metadata !{void (float*)* @metadata_kernel, metadata !"kernel", i32 1} Is clang going to support the emission of this metadata soon ? Or do I have to write it on my own ? :) Thanks,

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high level hammer to do ballpeen > work..... But when in Rome.... :-)

Hi all is it possible to avoid the emission of metadata information by opt and/or clang? For instance, I would like to go without "tbaa" metadata in LLVM assembly code as printed by "-emit-llvm". I'm using the 3.1 binary release for MinGW (and for Linux on a different machine). Best regards Nikolaos Kavvadias

You can turn off TBAA metadata by passing -fno-strict-aliasing to clang. You can turn off emitting debug metadata by not passing -g. There is no flag for turning off metadata in general (for example, range metadata will still be produced for certain casts, and if you compile Objective-C for the GNU runtimes then you will still have some metadata attached to message sends. If you want to remove

On 01/03/10 21:14, Chris Lattner wrote: > On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: > >> On 23/02/10 14:58, Richard Osborne wrote: >> >>> I've recently changed the XCore target to implement BR_JT as a jump to a >>> series jumps. The jump table entries are expand inline in the function >>> so there is no longer a need to emit jump

Wait loop can be interrupted by signal, so if signals are raised periodically (e.g. SIGALRM) this loop may never finish. Use emission time as a base for fence timeout. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c

> Maybe a target-specific attribute instead? It would still apply to all CCs, > but would never be dropped. That would work too, yes. I proposed metadata because it looks like it can be dropped, but that is not a big issue. I would be OK with an attribute too if that is more convenient or we want to make sure it is kept. Cheers, Rafael

On 19 December 2013 14:31, Gao, Yunzhong <yunzhong_gao at playstation.sony.com> wrote: > Hi all, > > > > I would like to find out whether anyone will find it useful to add an x86- > > specific calling convention for reducing emission of vzeroupper > instructions. > > > > Current implementation: > > vzeroupper is inserted to any functions that use AVX

On Jul 17, 2008, at 3:33 PM, Bill Wendling wrote: > In CodeGen/DwarfWriter.cpp's EmitDebugLine file, these lines are > causing havoc on Mac OS X systems: > > // If there are no lines to emit (such as when we're using .loc > directives > // to emit .debug_line information) don't emit a .debug_line > header. > if (SectionSourceLines.empty()) >

On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: > On 23/02/10 14:58, Richard Osborne wrote: >> I've recently changed the XCore target to implement BR_JT as a jump to a >> series jumps. The jump table entries are expand inline in the function >> so there is no longer a need to emit jump tables at the end of the >> function. However the emission of jump tables at

[This email is either empty or too large to be displayed at this time]

Also there is a typo: it probably should read pseudo. Yuri

On Aug 26, 2010, at 10:50 AM, Yuri wrote: > Also there is a typo: it probably should read pseudo. A pseudo instruction is used internally without llvm, but it does not correspond directly to a real instruction in the target architecture. Before emitting the final compiled code, all the pseudo instructions must be expanded to real instructions. If you're seeing that error, it means that

On 08/26/2010 11:11, Bob Wilson wrote: > A pseudo instruction is used internally without llvm, but it does not correspond directly to a real instruction in the target architecture. Before emitting the final compiled code, all the pseudo instructions must be expanded to real instructions. If you're seeing that error, it means that something was not expanded. > So what is likely to