similar to: [LLVMdev] Proposal: New DAG node type for reciprocal operation

Sounds like a reasonable fit for a target-specific DAG combine. I suspect a target specific node wouldn't be necessary and the patterns could be matched directly. -Jim On Sep 20, 2012, at 3:26 PM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi, > > In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get more performance when (1) “b” is loop

--- On Thu, 9/20/12, Jim Grosbach <grosbach at apple.com> wrote: From: Jim Grosbach <grosbach at apple.com> Subject: Re: [LLVMdev] Proposal: New DAG node type for reciprocal operation To: "Weiming Zhao" <weimingz at codeaurora.org> Cc: llvmdev at cs.uiuc.edu Date: Thursday, September 20, 2012, 3:32 PM Sounds like a reasonable fit for a target-specific DAG combine. I

Yes, what I mean is a target independent node in the ISD::NodeType enum. I already did the node transformation DAGCombiner and target-specific lowering in the first place. It worked. But introducing a specific node will make the logic more clear. For example, in ARM, FDIV is a scalar operation. So, after DAGCombiner and Vector Type legalize, vectorized FDIV has been expanded into scalar versions,

Hi, When I’m compiling a code with –fvisibility=hidden –fPIC for ARM, I find that LLVM generates less optimized code than GCC. For example: test.cpp: void init(void *); int g0[100]; int g1[100]; int g2[100]; void foo() { init(&g0); init(&g1); init(&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

Hi Renato, It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. So it a constraint is a 64-integer type, it *probably* needs paired GPR. Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The

On Mar 13, 2013, at 10:15 AM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi Renato, > > It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. This is correct. > So it a constraint is a 64-integer type, it *probably*

This buildbot appears to have been failing for several weeks now ( http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/19490 ). Does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 11:17 PM Subject: buildbot failure in LLVM on clang-ppc64-elf-linux2 To: Aaron Ballman <aaron at

Hi Rafael, Yes, merging gv prevents linker to do garbage collection. Should it be implemented as a peephole pass? If we do it too early, the distance between GVs are not fixed yet. PS: Below is the GCC output with "extern" hidden: ldr r2, .L2 stmfd sp!, {r3, lr} .save {r3, lr} .LPIC0: add r0, pc, r2 bl _Z4initPv(PLT) ldr r1, .L2+4 .LPIC1: add r0, pc, r1 bl _Z4initPv(PLT) ldr

All llvm-devs, We're going to introduce the new possible implementation for such optimizations as reciprocal estimation instead of fdiv. In short it's a replacement of fdiv instruction (which is very expensive in most of CPUs) with alternative sequence of instructions which is usually cheaper but has appropriate precision (see genReciprocalDiv in lib/Target/X86/X86InstrInfo.cpp for

On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on

r175088 attempted to fix gcc inline asm compatibility with 64-bit operands by forcing these into even/odd register pairs the same way gcc always allocates such values. While the fix appears to work as such, it is not always activated when required. The patch makes the assumption that any inline asm statement relying on the even/odd allocation will make use of the %Hn syntax to reference the high

In fact to commit the change before dealing with worst-case performance is a good idea because here we have 2 different issues. But the main idea of this RFC is an attempt to show the better approach to to these kinds of transformations and to suggest to use this approach in the future. At the same time, I'm trying to explain that this patch is not the performance one because the

Hi Måns, Always forcing 64-bit operands into even/odd pairs may lead to subpoptimal register allocation because not all 64 bit data requires paired regs. It seems there is no general pattern to match. Maybe we should treat it case by case. Jakob, do you have any suggestions? Thanks, Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Does R graphics have a way to easily label the horizontal axis by the reciprocal of the scaled value? -- View this message in context: http://r.789695.n4.nabble.com/Graphics-Reciprocal-labeling-tp3949054p3949054.html Sent from the R help mailing list archive at Nabble.com.

I believe that this may be more appropriate here in r-devel than in r-help. The normal hazard function, or reciprocal Mill's Ratio, may be obtained in R as dnorm(z)/(1 - pnorm(z)) or, better, as dnorm(z)/pnorm(-z) for small values of z. The latter formula breaks dowm numerically for me (running R 2.4.1 under Windows XP 5.1 SP 2) for values of z near 37.4 or greater. Looking at the pnorm

Hi folks, I know, this is a fairly common question and I am really disappointed that I could not find a solution. I am trying to calculate Mahanalobis distances in a data frame, where I have several hundreds groups and several hundreds of variables. Whatever I do, however I subset it I get the "system is computationally singular: reciprocal condition number" error. I know what it means

I get this error while computing partial correlation. *Error in solve.default(Szz) : system is computationally singular: reciprocal condition number = 4.90109e-18* Why is it?Can anyone give me some idea ,how do i get rid it it? This is the function i use for calculating partial correlation. pcor.mat <- function(x,y,z,method="p",na.rm=T){ x <- c(x) y <- c(y)

Hi All, This is my R-version information:--- > version _ platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 7.1 year 2008 month 06 day 23 svn rev 45970 language R version.string R version 2.7.1 (2008-06-23) While calculating partial

Dear All: I am using lmer() {lme4} to analyze results from a reciprocal transplant experiment where the response variable is modeled as a function of two fixed effects and their interaction. Example data follow: #library(lme4) #library(gmodels)