search for: srclocs

----- Original Message ----- > From: "Diego Novillo" <dnovillo at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chris Lattner" <clattner at apple.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 7, 2014 8:07:19 AM > Subject: Re: [LLVMdev] RFC - Adding an optimization

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

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Diego Novillo" <dnovillo at google.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, March 6, 2014 5:54:02 PM > Subject: Re: [LLVMdev] RFC - Adding an optimization report facility? > > > On Mar 6, 2014, at

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, I'm trying to have a pure asm function (non inlined) that returns it's own value to the caller. ; Function Attrs: naked noinline optnone define i32 @callcatch(i32, i32) #3 !dbg !10103 { BasicBlock8472: call void asm "\0D\0Apushl %ebp\0D\0Amovl 8(%esp),%eax\0D\0Amovl 12(%esp), %ebp\0D\0Acalll *%eax\0D\0Apopl %ebp\0D\0Aretl\0D\0A", ""(), !dbg !10104, !srcloc

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

Hi all, I am currently looking for more accurate debug information. In particular I am interested into relating load and store IR instructions to the corresponding array subscript. Current debug information associate each instruction to the source code line they come from. I would like to extend this, for loads and stores only, to make metadata point to the source location where the array

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

Hello, In the following code snippet: %tmp49 = call i64 asm "movq %gs:${1:P},$0", "=r,im,,~{fpsr},~{flags}"(i64* @kernel_stack) #6, !dbg !6625, !srcloc !5841 I would expect for the inline asm call to receive two arguments because of the ${1:P} corresponding to a %P1 that will append the $1 to %%gs:. Can someone explain why there is only one argument in this call? Moreover,

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

I would like to begin a discussion about updating LLVM's opt-report infrastructure. There are some things I'd like to be able to do with optimization reports that I don't think can be done, or at least aren't natural to do, with the current implementation. I understand that there is a lot of code in place already to produce optimization remarks, and one of my explicit goals is to

I strongly suspect pointer union and pointer int pair style classes are the source of these... But perhaps I'm wrong On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > John, > > That’s a great post and really interesting data, thank you! > > On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote: > >

Hi, I am seeing a case, in a private port, of an inline asm with indirect memory references being allocated invalid registers (i.e. registers that cannot be used on loads). For example, the inline asm constraint is correct: call void asm sideeffect "MOV $$r0, $0\0AMOV $$r0, $1\0A", "*m,*m,~{r0}"(i16* @a, i16* %b) #1, !srcloc !1 but then $0 and $1 are allocated to registers

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)

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

> 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

Hi, Looks like "{" and "}" are lost when trying to use the combination of Clang and NVPTX, which may result into clash of definitions of the function-scope and asm-scope. Here is an example: > cat test.cu __attribute__((device)) __attribute__((nv_linkonce_odr)) __inline__ int __any(int a) { int result; asm __volatile__ ("{ \n\t" ".reg .pred

Hi Adam, Thanks for your input. If I understand correctly, you’re saying that we can handle the loop versioning issue by explicitly identifying new loops as they are created. So, the unswitching optimization, for example, would report that it unswitched loop-0 at source location X, creating loop-1 and loop-2, and then later the vectorizer would report that it was unable to vectorize loop-1 at