similar to: Loop Invariants Detection questions

Ty Eli for your answer. On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: > >> Hi all! >> >> I'm new here, and would like to implement my own Loop Invariant Detection >> adding some more information on Quasi-Invariants. >> >> First, is there anything

On Wed, Jan 18, 2017 at 8:05 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/18/2017 2:56 AM, Thomas RUBIANO wrote: > > Ty Eli for your answer. > > On Tue, Jan 17, 2017 at 8:11 PM, Friedman, Eli <efriedma at codeaurora.org> > wrote: > >> On 1/17/2017 7:12 AM, Thomas RUBIANO via llvm-dev wrote: >> >>> Hi all! >>>

Thank you again Eli, I would like to know if it's not better to use DependenceAnalysis to know which instruction depends on others… I'm running this pass on a simple example: … while.body: ; preds = %while.cond %1 = load i32, i32* %y, align 4 ← I1 %2 = load i32, i32* %y, align 4 %mul = mul nsw i32 %1, %2 ← I2 store i32 %mul, i32* %z, align 4

Hi, I'm trying to write a simple pass to print out Loop invariant instructions, using the Loop::isLoopInvariant(Instruction *I) function. it is giving me false value on instructions which should be loop invariant. the code i am using is: bool MyLoopPass::runOnLoop(Loop * L, LPPassManager &lpm){ BasicBlock* lat=L->getLoopLatch(); for (BasicBlock::iterator i = lat->begin(), e =

On Nov 17, 2010, at 2:20 AM, Sreeraj a wrote: > Hi, > I'm trying to write a simple pass to print out Loop invariant instructions, using the > Loop::isLoopInvariant(Instruction *I) > function. it is giving me false value on instructions which should be loop invariant. > > the code i am using is: The isLoopInvariant method just works for scalar operations like

Hi, I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass. I would love to get feedback on the best way to incrementally push in this change. Motivation: There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). We've had test

The funny thing is that i am manually able to hoist the Loop invariant instruction to the basicBlock terminator, by editing the human readable form and then using llvm-as to convert it into bytecode. On Thu, Nov 18, 2010 at 4:01 AM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 17, 2010, at 1:38 PM, Sreeraj a wrote: > > > Thanks Chris, > > > > I was

Thanks Chris, I was able to weed out loop invariant arithmetic instructions using isLoopInvariant function. when i try to do an instruction->moveBefore(bb->getTerminator()) i'm getting a seg fault. any obvious reasons that i'm missing out on? Thanks in advance On Wed, Nov 17, 2010 at 10:41 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 17, 2010, at 2:20

i am getting seg fault on functions like I->eraseFromParent also. I'm assuming that the problem comes when i change the loop structure. On Thu, Nov 18, 2010 at 4:05 AM, Sreeraj a <writetosrj at gmail.com> wrote: > The funny thing is that i am manually able to hoist the Loop invariant > instruction to the basicBlock terminator, by editing the human readable form > and then

I'm current facing an issue related to AliasSetTracker/LICM: the transitive closure of the alias sets is materially more conservative than individual aliasing queries and this conservatism leads to generally worse optimization in LICM. For instance, consider this module: declare i32 @only_reads() readonly declare void @escape(i32*, i32*, i32*) define void @f(i32 %count) { entry: %a =

Dear llvm contributors, Could you please advise me how to skip checks, which are performed in AliasSet::aliasesUnknownInst, of unknown instructions from different alias sets of an alias set tracker that is a parameter of ‘AliasSetTracker::add(const AliasSetTracker &AST)’? If this wasn’t available at the moment and someone could review me, I would try to implement it. A temporary patch can be

Thank you for the idea! Could you please explain it? If I’m not mistaken, you advise to insert the unknown insts of an every AS from AliasSetTracker::add(const AliasSetTracker &AST) into a smallptrset and consequently append it to merged alias sets from AliasSetTracker::findAliasSetForUnknownInst. I think that Philip proposed something similar to your approach in

2015-12-11 23:44 GMT+05:00 Hal Finkel <hfinkel at anl.gov>: > Hi Roman, > > The MemoryLocation objects are involved in findAliasSetForUnknownInst, but none are created there for the memset intrinsic. MemoryLocation objects are only involved for the regular memory accesses being compared to the unknown instruction. See AliasSet::aliasesUnknownInst in lib/Analysis/AliasSetTracker.cpp.

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu> > Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Andrew Trick" <atrick at apple.com>, "Richard Smith" > <richard at

Hi, > One way to fix this would be to have AliasSetTracker pretend that > pointers to constant memory never alias anything. That's a little > sneaky though, ... on the other hand it is simple and (presumably) effective. Do you think it really could cause trouble? Ciao, Duncan.

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

On 07/17/2014 01:51 PM, Chandler Carruth wrote: > > > 2. Would adding a canonicalization of if(c) { unreachable } to > llvm.invariant(c) would be worthwhile? > > > There was a long and painful attempt to implement invariants based on > the branch-to-unreachable pattern. It didn't work. I don't expect > these patterns to show up often organically and to

Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: > Thank you, Mikael. I can reproduce what you saw and am looking into it. Great! > Just curious, why do you run loop-deletion before licm and loop-idiom? As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was

> Can you explain why the alias sets are collapsed into one here? If I'm reading the code correctly, it is because the readonly call aliases all of %a, %b and %c. Since two pointers can be in two different alias sets only if they do not alias, %a has to be in the same alias set as the read only call and so does %b and %c. Therefore, all of them have to be in the same alias set. > Can

Hello everyone, I'm starting a new thread, as a follow-up to several older ones, on invariants in LLVM. Fundamentally, invariants are conditions that the optimizer is allowed to assume will be valid during the execution of the program. Many other compilers support a concept like this, MSVC's __assume, for example. GCC has a builtin called __builtin_assume_aligned which also neatly falls