search for: loopidiom

It seems LoopIdiomRecognizer pass recognizes one loop inside memSet as memset and replaces it with memset intrinsic, which might then be converted into memset call, resulting in infinite recursion. There is parameter -fno-builtins to prevent this, BUT when executing opt as "standalone", this parameter cann...

On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote: > > On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote: > >> How does this affect freestanding implementations? > > This transform is disabled with -fno-builtin or -ffreestanding. Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is

Hi all, I'm trying to get the llvm's IR from the source code of Polybench (OMP) https://github.com/cavazos-lab/PolyBench-ACC/tree/master/OpenMP. I noticed a considerable difference between the IR generated using clang -emit-llvm -fopenmp and clang -emit-llvm: * using the -fopenmp flag I get a simplified IR in which I read a single basic block where I can highlight a llvm.memcpy

...Aug 27, 2012, at 11:37 AM, gohman at apple.com wrote: > On Aug 24, 2012, at 5:56 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > > > If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct definition. > > Perhaps, though that would be unrelated in implementation and use from > what I'm working on. You're describing structure padding and doing so as metadata on memcpy operations. I think...

Hi all, I'm currently working on the implementation for LLVM of the RISCV Bit Manipulation ISA extension described by Clifford Wolf in the following presentation: https://content.riscv.org/wp-content/uploads/2019/06/17.10-b_wolf.pdf and the following document: https://github.com/riscv/riscv-bitmanip/blob/master/bitmanip-0.90.pdf The aim is to provide the intrinsic functions to the user in

Hi Roman, > That depends. > If there's LLVM intrinsic for it, then any normal optimization pass could do it. > In cttz's case it's mainly done in LoopIdiom pass. Oh yes. Thank you! Unfortunately several of the instructions of the bit manipulation extension don't seem to have an intrinsic already in LLVM. That will require to add some passes to the middle end. > Again, i'd say this is too broad of a question. > If there is LLVM IR intr...

If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct definition. Alex On Aug 22, 2012, at 1:15 PM, Dan Gohman wrote: > Hello, > > Currently LLVM expects front-ends to lower struct assignments into either > individual scalar loads and stores, or calls to @l...

...he annotation does not matter, but for others it might. In those cases having a general way to encode the rules would indeed be very helpful! I think Francis already took a look at some passes that would need updating when annotating auto-init stores. Most of the problematic transforms (like SROA, LoopIdiom and InstCombine) are combining stores to stores of wider types or various mem* intrinsics. As an initial general rule, it probably makes sense to preserve any annotation metadata, if all combined instructions share the same metadata? I think it would make sense to start with something like that an...

...with". It sounds like having a set to express these rules for all kinds of metadata would be useful, not just for !annotation. >> I think Francis already took a look at some passes that would need updating when annotating auto-init stores. Most of the problematic transforms (like SROA, LoopIdiom and InstCombine) are combining stores to stores of wider types or various mem* intrinsics. As an initial general rule, it probably makes sense to preserve any annotation metadata, if all combined instructions share the same metadata? > > Keeping identical annotation, sure. Otherwise, the pas...

...LLVM :: CodeGen/X86/atomic16.ll**** > > LLVM :: MC/ARM/arm-shift-encoding.s**** > > LLVM :: MC/ARM/thumb-shift-encoding.s**** > > LLVM :: MC/COFF/global_ctors_dtors.ll**** > > LLVM :: Transforms/InstCombine/div-shift.ll**** > > LLVM :: Transforms/LoopIdiom/non-canonical-loop.ll**** > > LLVM :: Transforms/SROA/basictest.ll**** > > LLVM :: Transforms/SROA/phi-and-select.ll**** > > ** ** > > I haven't yet looked at them in detail, and obviously on the last two > clearly involve SROA, but given that these tests have...

...oils down to defining reasonable "categories", e.g., "replace-by", "moved", "merged-with". > > I think Francis already took a look at some passes that would need updating when annotating auto-init stores. Most of the problematic transforms (like SROA, LoopIdiom and InstCombine) are combining stores to stores of wider types or various mem* intrinsics. As an initial general rule, it probably makes sense to preserve any annotation metadata, if all combined instructions share the same metadata? Keeping identical annotation, sure. Otherwise, the pass should c...

After a lot of testing and help from Duncan, Benjamin, Joerg and others, I think the new SROA is ready for some broader testing. I've fixed all the crashers and miscompiles that Duncan and Joerg have been able to find (although I'm sure there are a few left I'll tackle when there are reports), and the LNT numbers look *really* good. Here is the latest LNT run we got by flipping it on

...ptLevel < 3, DivergentTarget)); MPM.add(createCFGSimplificationPass()); addInstructionCombiningPass(MPM); MPM.add(createIndVarSimplifyPass()); // Canonicalize indvars // <I probably want to add some SimplifyCfg pass here, but // that's a separate issue> MPM.add(createLoopIdiomPass()); // Recognize idioms like memset. addExtensionsToPM(EP_LateLoopOptimizations, MPM); MPM.add(createLoopDeletionPass()); // Delete dead loops if (EnableLoopInterchange) { MPM.add(createLoopInterchangePass()); // Interchange loops MPM.add(createCFGSimplificati...

Hi, I would like to propose a new !annotation metadata kind that can be attached to arbitrary instructions to drive generating remarks that provide additional insight into transformations applied to a program. To motivate this, consider these specific questions we would like to get answered: * How many stores added for automatic variable initialization remain after optimizations? Where are