similar to: trouble hoisting GlobalValues

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Steve King" <steve at metrokings.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 4:28:33 PM > Subject: Re: [llvm-dev] trouble hoisting GlobalValues > > On 11 December 2015 at 16:53, Steve

In the following IR module: – define i8 @foo() #0 { entry: %call0 = call i8 @bar() ret i8 %call0 } declare i8 @bar() #1 – @bar() gets marked as its own user in top-of-tree LLVM. I patched the Verifier to check it (but didn’t commit the patch): – Index: lib/IR/Verifier.cpp =================================================================== --- lib/IR/Verifier.cpp (revision 203468) +++

Hi, I am debugging private backend and faced interesting problem: sometimes spill hoisting creates double stores. (some output from -debug-only=regalloc). First hoisting: Checking redundant spills for 0 at 16r in %vreg19 [16r,144B:0)[144B,240B:1)[240B,280r:2)[296r,416B:3)[416B,456r:4)[472r,592B:5) 0 at 16r 1 at 144B-phi 2 at 240B-phi 3 at 296r 4 at 416B-phi 5 at 472r Merged to stack int: SS#0

Chris, this is a patch against top-of-tree. Maybe I wrote something wrong in the patch? $ svn info … Last Changed Author: chapuni Last Changed Rev: 203523 Last Changed Date: 2014-03-10 17:34:38 -0700 (Mon, 10 Mar 2014) $ svn diff Index: lib/IR/Verifier.cpp =================================================================== --- lib/IR/Verifier.cpp (revision 203523) +++ lib/IR/Verifier.cpp

Hi, I have the below test case. --snip-- struct st { int a; int b; }; int * ptr; int x,y; void bar(int *x); void foo() { struct st obj; bar(&obj.b); if(x) obj.a =x; else obj.a =y; for (int i=0; i<obj.a;i++) ptr[i]=i; } --snip-- LLVM IR produced at -O3 is shown below. ref: https://godbolt.org/z/WPlmfr --Snip-- %8 = getelementptr inbounds %struct.st,

hi, I applied licm with basicaa on the following codes: int j = atoi(argc[1]); int lower[] = {10, 9, 8, 7, 6, 5, 4, 3, 2, 1}; int upper[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for(i = lower[j]; a[i] < 100 && i < upper[j]; i ++); I notice that upper[j] is not hoisted out from the loop. Is this because j could be larger than 10? Thanks a lot! Best,

Hi, I was tracking down a performance regression and noticed that LoopStrengthReduce hoists loop invariants (e.g., the initial formulae of indvars) in the reverse order of how they appear in the loop. This reverse order creates troubles for the StraightLineStrengthReduce pass I recently add. While I understand ultimately SLSR should be able to sort independent candidates in an optimal order,

----- Original Message ----- > From: "Ashutosh Nema" <Ashutosh.Nema at amd.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, February 11, 2015 3:20:27 AM > Subject: Re: [LLVMdev] question about licm > > Hi, > > LICM can only hoist instructions which dominates all loop exit > blocks. > In this case

_mm_lfence was originally documented as a load fence. But in light of speculative execution vulnerabilities it has started being advertised as a way to prevent speculative execution. Current Intel Software Development Manual documents it as "Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

I think this is preventing constants in the constant pool (e.g., floating point literal) from being placed in the mergeable constant sections? We want to keep the const arrays declared in the program (s_dashArraySize1) out of the mergeable constant sections, but don't mind placing constants in the constant pool or constant arrays that the compiler defines, such as switch.table and

Hi Chris, If you have everything setup to test, can you generate the LLVM IR with -03 from 3.4.1 and 3.5 to be sure they match. Then we can focus on the backend. Thanks, Mehdi > On Feb 3, 2015, at 1:58 AM, Chris Sears <chris.sears at gmail.com> wrote: > > So between 3.4.1 and 3.5 since it isn't in 3.4.1 and it is in the current XCode. -------------- next part

Hi Craig, The review for the similar GPU problem is now up here: https://reviews.llvm.org/D85603 (+ some other patches on the Phabricator stack). >From a pragmatic perspective, the constraints added to program transforms there are sufficient for what you need. You'd produce IR such as: %token = call token @llvm.experimental.convergence.anchor() br i1 %c, label %then, label %else

Hi Krzysztof, Could I get some background info on reasoning about hoisting in the presence of volatile loads? I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll Context: MemorySSA treats volatile loads as defs. I'm looking to better understand expected behavior in the presence of volatile accesses. More context: https://reviews.llvm.org/D40375. Thanks in advance, Alina

Hi, Within a basic block I can remove unnecessary register copies + zero sign extensions of unsigned-8bit-loaded values by implementing isZExtFree() for ISD::LOAD nodes. ...But not between basic blocks. The first block does a CopyFromReg of the unsigned-8bit-loaded vreg1 into a new vreg2. The second block then does a unnecessary zext to vreg2. What I want is the 2nd block to use the original

Hi, I am trying to update the initializer of a global value and I have encounter two issues: The first one is that I can not change the type of the global value. Let say that I have the following variable: @.str = private unnamed_addr constant [6 x i8] c”Test0A\00", align 1 How can I change the ”Test0A\00” to ”OtherTest0A\00”. Is this possible? I know that you can change the initializer

Hi, I recently looked into the LICM(Loop Invariant Code Motion) pass of LLVM and got a question about hoist load instruction to loop preheader. I would like to show two examples: Example 1: int func(int n, int *fp) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += *fp; // load from *fp pointer, no hoist } } Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp

I looked at an earlier version. NamedMDNodes were linked after global values. Current trunk version links NamedMDNodes before that, though the comment says otherwise: "We do this after linking GlobalValues so that MDNodes that reference GlobalValues are properly remapped". see ModuleLinker::run in lib/Linker/LinkModules.cpp. If I move the call to linkNamedMDNodes in ModuleLinker::run

Hi Mehdi, Thank you for you answer. > Yes it is normal you *have* to use the same context to manipulate IR inside a Module. The context owns the module and destroying the context destroys everything that is created in the context. It is not clear to me what other context you could even manage to use here conceptually. Actually I was using llvm::getGlobalContext() in order to get the context.

Hi, A bit more information. I believe my problem lies with the fact that the load is left as 'anyext from i8'. On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! If BB#1 were to force the load to a "zext from i8" would this information be available in BB#2? BB#1: 0x268c1b0: i32 = Register %vreg1 [ID=3] 0x2689d80: