similar to: [LLVMdev] Sub registers in inline assembly

On Mar 1, 2011, at 1:24 PM, Damien Vincent wrote: > > I was wondering if llvm supports sub registers in an inline asm string. > For example, in gcc, using modifiers %w0 makes it possible to access ax if %0 refers to eax. > > If there is any support, do you know where it is implemented ? I'd like to add such a support for another target. Hi Damien, It sure does. These

On Wed, Feb 07, 2018 at 08:44:32PM +0000, David Woodhouse wrote: > On Wed, 2018-02-07 at 10:11 -0800, Guenter Roeck wrote: > > > On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote: > > > Hm, please could we also have the %V asm constraint modifier? That > > > allows us to emit calls to the thunks from inline asm using the > > > register that the

On Wed, 2018-02-07 at 21:55 +0000, David Woodhouse via llvm-dev wrote: > Can you take care of filing the tickets for %V0 and "=q" > and attribute__((indirect_branch("keep"))) please? With those fixed, I > think we should be OK again. Here's %V0 support, which makes the hypervisor guest support build. diff --git a/lib/Target/X86/X86AsmPrinter.cpp

On Wed, 2018-02-07 at 13:16 -0800, Guenter Roeck wrote: > Here are my exact versions: >     llvm: 3afd566557f3 ("AMDGPU: Add 32-bit constant address space") >     clang: 848874aed95a ("[clang-format] Fix ObjC message arguments formatting.") OK, mine are slightly newer than that now, but I now get a working 64- bit defconfig build. It'll still break with any PV

All, If we can speculatively execute a load instruction, why isn’t it safe to hoist it out by promoting it to a scalar in LICM pass? There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have

I think gcc is right. It inserted a branch for n == 0 (the cbz at the top), so that's not a problem. In all other regards, this is safe: if you examine the sequence of loads and stores, it eliminated all but the first load and all but the last store. How's that unsafe? If I had to guess, the bug here is that LLVM doesn't want to hoist the load over the condition (which it is right

How to use R to solve the optimisaton problem Minimize: ?*w^T*omega*w+mu^T*w+c^T(w-w0) for w>w0 long position ?*w^T*omega*w+mu^T*w-c^T(w-w0) for w<w0 short position W: is the update weight of portfolio Wo is the initial weight of portfolio Omega is the variance covariance matrix mu is the vector of return rate of stocks in the portfolio C is the vector coefficient of transaction cost

Hello, I am having a hard time fitting a gauss beam using R. In gnutplot I did something like $ w(z) = w0 * sqrt(1+(z/z0)**2) $ fit w(z) 'before_eom.txt' using 1:2 via w0, z0 to obtain w0 and z0. Now I want to do the same in R. I tried a linear model like this (r = radius, z = distance): beam <- function(z) { sum(sqrt(1 + z**2)) } lm(r ~ I(beam(z)), data = before_eom) Which

In Version 1.1.0 Under development (unstable) (June 8, 2000) there seems to be a problem with an internal variable w0 in legend that generates the following new error: Error in legend((par()$usr)[1:2], (par()$usr)[3:4], Legend, lty = lty, : Object "w0" not found > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read

Thanks for the background on the concurrent memory model. So, is it sufficient that the loop entry is guarded by condition (cbz at top) for preventing the race? The loop entry will be guarded by condition if loop has been rotated by loop rotate pass. Since LICM runs after loop rotate, we can use ScalarEvolution::isLoopEntryGuardedByCond to check if we can speculatively execute load without

Hello, Rlisters I have to compute p-values that are on the tail of the distribution, P-values < 10^-20. However, my current implementations enable one to estimate P-values up to 10^-12, or so. A typical example is found below, where t is my critical value. ########### example - code adapted from Rassoc ####################### rho01 = 0.5 rho105 = 0.5 rho005 = 0.5 t = 8 z = 2

Hi llvmdev! I've been working on adding coroutines to LLVM. Mentioned below is the implementation plan I'm following, for suggestions, flames and other input. Using segmented stacks is a prerequisite. The idea is to associate every coroutine with a coroutine descriptor. A coroutine descriptor consists of four words: w0, w1, w2 and w3. w0 always contains the _launcher_, and invoking a

Interesting - the patch doesn't address this yet. It looks like we have a difference (maybe bug?) in how we handle Intel vs. AT&T inline assembly: https://godbolt.org/z/GQw9ED Suppose we're expanding an operand with an 'i' constraint, where the operand is given as, e.g. (i32* @Bar). If the inline assembly is in Intel dialect, this expands as "Bar" in AT&T syntax

Here are my patches to add edge + button functionality. I still feel that there is a problem with gconf, but I have just made it so that the edge button functionality works. I have included a patch for gconf to display AnyButton if it is set to 0. There is also a patch to make the edge size configurable because 1 pixel was too small and the mouse keeps slipping off when using it for the

Hello, For a very simple loop where all IV users are post-inc users, I observed redundant add instructions in AArch64. From LSR debug, I can see initial formula for icmp is the one that transformed to a post-inc form in OptimizeLoopTermCond() and later expanded in post-inc mode. Based on the observation that the icmp is already a post-inc user, I hacked LSR to prevent the icmp from being

i want to emit binary code for the following implemented vector assembly instructions. P_256B_LOAD_DWORD R_0_R2048b_0, pword ptr [rip + b] P_256B_LOAD_DWORD R_0_R2048b_1, pword ptr [rip + c] P_256B_VADD R_0_R2048b_0, R_0_R2048b_1, R_0_R2048b_0 P_256B_STORE_DWORD pword ptr [rip + a], R_0_R2048b_0 I added the following lines in X86MCInstLower.cpp; unsigned NewOpc; switch (OutMI.getOpcode())

Saving lda.default as text files from within gui="none" and from within gui="gnome" and comparing afterwards with diff, I get: alobo at humboldt:> diff lda.default.gnome.txt lda.default.nognome.txt 1c1 < function (x, grouping, prior = proportions, tol = 1, method = c("moment", --- > function (x, grouping, prior = proportions, tol = 1e-04, method =

Currently the AtomicExpandPass will lower the following IR: define i1 @foo(i32* %obj, i32 %old, i32 %new) { entry: %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new _*release acquire*_ %v1 = extractvalue { i32, i1 } %v0, 1 ret i1 %v1 } to the equivalent of the following on AArch64: _*ldxr w8, [x0]*_ cmp w8, w1 b.ne .LBB0_3 // BB#1:

Hello, We're evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int

> On May 27, 2016, at 2:50 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > For a very simple loop where all IV users are post-inc users, I observed redundant add instructions in AArch64. > > From LSR debug, I can see initial formula for icmp is the one that transformed to a post-inc form in OptimizeLoopTermCond() and later expanded in post-inc