similar to: [LLVMdev] Inline asm call argument mismatch?

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

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

Hello, Most of the IR language is correctly explained; but with inline assembly I feel alone at some point: define i32 @main(i32 %argc, i8** %argv) #0 { ... //some uninteresting bloat here call void asm sideeffect "outw %eax, $0", "imr,~{dirflag},~{fpsr},~{flags}"(i32 %8) #2, !srcloc !2 ret i32 0 } I reduced the above code to the offending line containing:

Hi all, I'm trying to land (a rebased version of) http://llvm.org/D37461 - which should make it possible to handle x86 Intel assembly like mov eax, offset Foo::ptr + 1 (Currently, omitting the +1 works... but offset doesn't work in compound expressions.) I'm having trouble figuring out what inline assembly I can emit into the LLVM IR that will work properly. So far, the closest

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

On Jul 31, 2009, at 10:24 AM, Michael Graumann wrote: > Hi, > I’ am trying to insert an InlineAsm Instruction in my pass, which > FunctionType do I need for Inlineasm? > If I understand it right, I need a call instruction to insert the > new produced InlineAsm? > > Thanks for help Inline asm works like a "callee". So for: call void asm sideeffect

Hi, I' am trying to insert an InlineAsm Instruction in my pass, which FunctionType do I need for Inlineasm? If I understand it right, I need a call instruction to insert the new produced InlineAsm? Thanks for help, Michael for (BasicBlock::iterator bi = i->begin(), be = i->end(); bi != be; ++bi){ std::vector<const Type*> asm_arguments;

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", >

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", "={ax},0,{di},~{dirflag},~{fpsr},~{flags}"(i64 231, i64 %41) nounwind ; <i64> [#uses=2] -Rich

Hey all, I'd like to propose a new intrinsic for use in preventing optimizations from deleting IR due to constant propagation, dead code elimination, etc. # Background/Motivation In Rust we have a crate called `test` which provides a function, `black_box`, which is designed to be a no-op function that prevents constprop, die, etc from interfering with tests/benchmarks but otherwise

Thanks, but I could not find the imr, dirflag, fpsr constraints here. Just the usual gcc/clang inline assembly constraints. Those one were of my concern, actually :) --  Alex 18.11.2015, 17:11, "David Siegel" <agnat at icloud.com>: >>  On 18.11.2015, at 16:28, AlexandreFressange via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>  I reduced the above

Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are clobbering EFLAGS on x86_64. This is inconvenient when the status of bit 9 (IF), which controls interrupts, changes. Here's a simple test program. Assume that the external function foo() modifies the IF bit in EFLAGS. --- #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void)

HI, When compiling the open-source software cryptopp (https://www.cryptopp.com/#download <https://www.cryptopp.com/#download>) version 5.6.4 I found a strange issue with the IR generated. The issue only appears when compiling with -O2 optimisation in the integer.cpp file (the function is _ZN8CryptoPPrsERNSt3__113basic_istreamIcNS0_11char_traitsIcEEEERNS_7IntegerE ->

Hi, I would like to prevent that two adjacent calls to external functions getting interleaved/separated by other neighboring code. This mixing seems to happen in the code generator. I can prevent it by putting the two calls into a separate BB, but then I can't use -simplifycfg, -jump-threading, ... as is. Here is an example: %160 = add i64 %158, %159 ; <i64>

> On Mar 1, 2015, at 7:53 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > On 2015.02.28 18:17:27 -0800, Philip Reames wrote: >>> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>> 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: >>>>>> On Feb 28, 2015, at 2:30 PM, Björn

> On Feb 28, 2015, at 3:01 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > > [This time without dropping the list, sorry] > > 2015-02-28 23:50 GMT+01:00 Philip Reames <listmail at philipreames.com>: > >>>> On Feb 28, 2015, at 2:30 PM, Björn Steinbrink <bsteinbr at gmail.com> wrote: >>>> >>>>> On 2015.02.28

Hi everyone. On i386--win32 targets, LLVM tries to use the MSVCRT routine _ftol2 for floating-point to unsigned conversions, but this function has a nonstandard calling convention LLVM doesn't understand. It takes its input operand on the x87 stack as ST0, which it pops off of the stack before returning. The return value is given in EDX:EAX. In effect, I need to call it like this: %1 = call

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