similar to: [LLVMdev] Volatile Functions

On 12/20/2017 03:49 PM, Alina Sbirlea via llvm-dev wrote: > +Philip to get his input too. > I've talked with George offline, and here's a summary: > > In D16875 <https://reviews.llvm.org/D16875>, the decision made was: > "The LLVM spec is ambiguous about whether we can hoist a non-volatile > load above a volatile load when the loads alias. It's probably

Hello devlopers, I request your guidance on how to lower the metadata attached with an instruction. Following is given the IR dump before Module verifier pass, and there is a string "Tile3" attached as metadata with instruction "%x = alloca i32, align 4, !Tile3 !1". My target is to transmit/propagate the string down to post RA-Scheduling pass. Is it possible? If yes, how

Hi Andy and list, Just to give you a follow up, I was implementing a transformation pass just as you recommended at the time I sent the email to the list, but at that time I was worried that the code generator would change the order of the instructions created in the LLVM-IR. Indeed, that was the case. Some instructions after ISel were added between the volatile store instructions (which is

On Mar 7, 2012, at 11:34 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I filed a bug report (Bug 12205). > Please take a look when you have time. > > Per your suggestion, I also attached a patch which attaches to load or > store nodes a machinepointerinfo that points to a stack frame object > when it can infer they are actually reading from or writing to the >

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

Jonas Maebe via llvm-dev wrote: > Then, I tried the following: > a) if the longjmp for the try-block is taken (i.e., the setjmp right > before the try-block returns a non-zero value), jump to the landingpad BBL. > > -> Problem: LLVM does not allow regular jump edges to landingpad BBLs > > b) since the landingpad is empty anyway and falls through into the next > BBL

On Sun, Dec 18, 2016 at 11:58 PM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > > Actually, there's another —even more fundamental— problem: the longjmp > will always restore the non-volatile registers to the contents they had > at the start of the try-block, which is not what LLVM expects when > entering an SEH-based landing pad. > The SjLjEHPrepare pass tries

Dear R-users, I am trying to develop a function that takes another function as an argument, changes its default values and returns a list of things, among which the initial function with its default arguments changed. An example of what i will like to obtain below: ## initial function myfun <- function(x, a=19, b=21){ return(a * x + b) } ## this is the function i will like to create ##

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

On Mar 24, 2008, at 10:47 PM, Christopher Lamb wrote: > I know that this has been discussed (at least in passing) a few > times on the list, but I couldn't locate a bug for it. Have any > architectural plans been made for it? Funny you bring this up. Evan and I were tossing around crazy ideas about this just today. If you're interested, maybe we should get together for

Thank you for your suggestions. I implemented the first approach (provided the byval argument and offset to MachinePointerInfo) and it seems to have fixed the instruction ordering problem. It was a lot simpler than initially expected. In this particular case, is the user responsible for providing alias information to MachinePointerInfo to guarantee instructions are emitted in the correct order?

On 12/20/2017 1:37 PM, Sanjoy Das wrote:> > Fwiw, I was under the impression that regular loads could *not* be > reordered with volatile loads since we could have e.g.: > > int *normal = &global_variable; > volatile int* ptr = 0; > int k = *ptr; // segfaults, and the signal handler writes to *normal > int value = *normal; > > and that we'd have

Hi, I'm try to lower the store LLVM-IR instruction as per the following LLVM IR program: *** IR Dump After Module Verifier *** define void @storeloadi32() { %ptr = alloca i32 store volatile i32 12, i32* %ptr ret void } The target instruction is associated to the store like this: def MOVSUTO_A_iSLr : CLPFPU_A_iSLr<0b1000001101,

On 01/20/2013 10:56 PM, Chandler Carruth wrote: > I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this > seems like an easy and simple deficiency in the IR intrinsic for > memcpy. See below. > > On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison > <arnaud.allarddegrandmaison at parrot.com > <mailto:arnaud.allarddegrandmaison at

On Wed, Sep 4, 2013 at 2:33 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org > wrote: > A customer has reported a performance problem, which I have eventually > tracked down to the following situation: > > Consider this program: > > int foo(int *p, volatile int *q, int n) { > int i, s = 0; > for (i = 0; i < n; ++i) > s += *p + *q; > return s;

Are you sure this is an alias problem? What is happening is LLVM is leaving the code looking like this: int foo(int *p, volatile int *q, int n) { int i, s = 0; for (i = 0; i < n; ++i) s += *p + *q; return s; } but GCC is changing to code to look like this: int foo(int *p, volatile int *q, int n) { int i, s = 0; int t; t = *p; for (i = 0; i < n; ++i) s += t + *q;

I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this seems like an easy and simple deficiency in the IR intrinsic for memcpy. See below. On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison < arnaud.allarddegrandmaison at parrot.com> wrote: > define void @test(i16 zeroext %a) nounwind uwtable { > %r.sroa.0 = alloca i16, align 2 > %r.sroa.1 = alloca i16,

As a results of my investigations, the thread is also added to cfe-dev. The context : while porting my company code from the LLVM/Clang releases 3.1 to 3.2, I stumbled on a code size and performance regression. The testcase is : $ cat test.c #include <stdint.h> struct R { uint16_t a; uint16_t b; }; volatile struct R * const addr = (volatile struct R *) 416; void test(uint16_t a) {

Daniel, Thanks a lot for the pointer, that's very helpful! I'll use that as a guide to update how we handle volatile accesses. Mind if I ask for feedback when I update the patch? Krzysztof, Thanks for the answer, that was very informative! I appreciate it! Best, Alina On Wed, Dec 20, 2017 at 5:33 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Hi Alina, > The

This is a bug fixing. So it needs go into 4.1. x86: add volatile prefix for cpuid asm clauses cpuid results are possible to be changed now. For example, changing CR4.OSXSAVE bit or setting MSR XCR_XFEATURE_ENABLED_MASK may change XSAVE related cpuid leave return values. The volatile prefix is required to avoid the second cpuid calls following some possible changing operations being optimized in