similar to: Mapping stack to IR on x86 backend

Hi all, I'm getting rather odd behavior from a call asm inteldialect(). TL;DR is "mov reg, $0" with a "i" constraint on $0 is behaving identical to "mov reg, dword ptr [$0]" and differently from "movl $0, reg" in AT&T syntax. I'm not sure how to get clang to emit an inteldialect, so for this example, I'm emitting llvm and then modifying

> On Jan 7, 2020, at 18:41, Craig Topper <craig.topper at gmail.com> wrote: > > What version of llvm are you using? This looks like it may be fixed on trunk. After poking at my installation of rust, I'm not entirely sure what version of LLVM it uses. Looking at the GitHub page, it looks like Rust maintains their own copy of llvm and cherry picks commits. The C example was

One more interesting thing I have noticed is as following : In sqlite3 code consider 3 functions namely sqlite3Update, sqlite3Select and sqlite3Where begin sqlite3WhereBegin is called by both functions sqlite3Update and sqlite3Select but according to CallGraphSCC sqlite3Update is codegen before in that case during RegMask propagation phase default regmask is used for call site of

Hello Mentors, I am currently finding bug in Local Function related optimization due to which runtime failures are observed in some test cases, as those test cases are containing very large function with recursion and object oriented code so I am not able to find a pattern which is causing failure. So I tried following simple case to understand expected behavior from this optimization. Consider

In the Zig frontend, we know at compile-time the entire call graph. This means we know stack size for all functions and therefore the upper bound stack usage. Recursive calls can have a runtime-decided stack usage, and therefore I am adding a frontend feature that will heap-allocate memory to use for some function calls. The idea is that recursion adds cycles to the call graph, and we know at

Hi all, I stumbled upon either a bug, or we are emitting wrong inline asm code. The testcase is: ``` source_filename = "testcase.d" target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx" define void @_D7asanasm3fooFZv() { %a = alloca [4 x i32], align 32 call void asm sideeffect "movl %ebx, 4+$0",

Hi, Apologies this is a bit lengthy. TLDR: I'm using Dragonegg + LLVM 3.2 and uClibc, and am finding that using the Fast register allocator (i.e. -optimize-regalloc=0) causes miscompilation of setsockopt calls (5-arg system calls). The problem doesn't happen with the default register allocation path selected. It can be worked around by manually simplifying the system call setup

Hi all, I'm working for translating dex bytecode to LLVM IR In order to communicate with Android interpreter, The work have to add data below some instructions I want to use inline assembly to add data. Thus, I wrote a little program to find out the related LLVM IR int main() { asm(".long 0x12345678"); return 0; } and I use clang to translate it into bitcode It's the

Hi Jian-Ru Chen, if you run llc on your bitcode with -march=cpp then it should output the series of API calls needed to produce that bitcode. Ciao, Duncan. On 07/06/13 12:18, Jian-Ru Chen wrote: > Hi all, > I'm working for translating dex bytecode to LLVM IR > In order to communicate with Android interpreter, > The work have to add data below some instructions > > I want to

Hi, Is there something wrong with my inline assembly below? *** target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.5" define void @"\01_SYSTEM_$$_SETMXCSR$LONGWORD"(i32 %p.w) nobuiltin { ; [71] procedure

Eli Friedman wrote: > 2009/8/2 Richard Pennington <rich at pennware.com>: >> The following fails on x86_64 because of the output constraint '0'. >> My question is, is this legal. LLVM complains about the size difference >> (32 vs 64), but it is the same register (ax). >> Works on x86. >> >> %42 = call i64 asm sideeffect

2009/8/2 Richard Pennington <rich at pennware.com>: > Eli Friedman wrote: >> 2009/8/2 Richard Pennington <rich at pennware.com>: >>> The following fails on x86_64 because of the output constraint '0'. >>> My question is, is this legal. LLVM complains about the size difference >>> (32 vs 64), but it is the same register (ax). >>>

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

Hi all, I'm trying to run the Larousse Multilingue Dictionnary pack. I've tried to run it under wine 0.9.17 (from codeweaver), 0.9.25 (from debian testing) 0.9.28 (from debian unstable) and 0.9.29 (from source). My wine setting is functional since I can use an older Larousse dictionnary (Bibliorom), no problem at all for any of the versions above. I downloaded a (legal) version of the

On Fri, Jun 6, 2008 at 6:32 AM, Tomas Lindquist Olsen <tomas.l.olsen at gmail.com> wrote: > Hi all, > > I'm having some trouble with inline asm expressions, more specifically > how to create the right FunctionType for a given constraint set. > So far it has worked well for inputs, but not for outputs. The inline > asm support in this language (which is D, LLVMDC[1]) is

Hi all, I'm having some trouble with inline asm expressions, more specifically how to create the right FunctionType for a given constraint set. So far it has worked well for inputs, but not for outputs. The inline asm support in this language (which is D, LLVMDC[1]) is through asm *statements*. I never have inline asm *expressions*, and outputs are always via memory. I D my test looks like

On 9/5/20 12:40 AM, Atmn Patel wrote: > On Sat, Sep 5, 2020 at 1:07 AM Johannes Doerfert > <johannesdoerfert at gmail.com> wrote: >> >> On 9/4/20 7:39 PM, Hal Finkel via llvm-dev wrote: >> > >> > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> >> Hi All, >> >> >> >> We’ve prepared a new function attribute

On Wed, Jul 15, 2015 at 11:00 PM, Chandler Carruth <chandlerc at google.com> wrote: > FWIW, I'm very much in favor of having a firm and clear answer to these > questions. > > I also agree that it is an absolute requirement that LLVM have *some* > mechanism for supporting both languages with defined behavior for infinite > loops and a language requirement that all loops

2009/8/2 Richard Pennington <rich at pennware.com>: > The following fails on x86_64 because of the output constraint '0'. > My question is, is this legal. LLVM complains about the size difference > (32 vs 64), but it is the same register (ax). > Works on x86. > > %42 = call i64 asm sideeffect "syscall\0A\09", >

On Fri, Jun 6, 2008 at 9:29 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 6, 2008 at 6:32 AM, Tomas Lindquist Olsen > <tomas.l.olsen at gmail.com> wrote: >> Hi all, >> >> I'm having some trouble with inline asm expressions, more specifically >> how to create the right FunctionType for a given constraint set. >> So far it has