search for: constantmerge

Hello, It seems I stepped on a bug with the ConstantMerge IPO pass, regarding address spaces. For example, if a module contains the following: @a = internal constant i16 224 @b = internal addrspace(30) constant i16 224 Although a & b have the same initializer, i think they should not be merged. Attempting to do it anyway will trigger an assertion....

> If you're running opt on the command line directly, then use the > "-p" option. See "-help" for more information on that. > > -bw > I have a couple of more questions. 1. Does -std-compile-opts of opt do the same optimization with llvm-gcc with -O[1-3] options? If I want to debug into passes through llvm-gcc, how do I set a breakpoint right before pass

...getPreferredAlignment() to determine number of trailing zeros of the address of a global defined in the current module. * lib/Transforms/Utils/InlineFunction.cpp - Uses getPrefTypeAlignment() to set the alignment of the alloca it introduces when a byval argument is inlined * lib/Transforms/IPO/ConstantMerge.cpp - Uses getPreferredAlignment() to determine the alignment of the merged constant. * lib/Transforms/Vectorize/BBVectorize.cpp - Depending on what options are set this pass avoids vectorization if it would introduce loads and store of less than the alignment returned by getPreferredAlignment()...

...hat malloc(1) == malloc(1) can be true in some situations! Now, this doesn't actually work because malloc elimination transformation isn't quite aggressive enough, but making this work wouldn't require any controversial changes. This bug actually manifests itself in two places: one is ConstantMerge, the other is the AsmPrinter. It's non-trivial to fix because it's really a design bug: we assume that constant==mergeable, which simply isn't true. There are a few different ways of fixing this; however, I think the only real option is to add a new "mergeable" linkage type....

Hi Everyone, Can Someone tell me all the interprocedural optimizations that LLVM 2.1 supports. Thank You, Naineet Patel CSE IITB

...nt for a global, and assuming that nothing later than it will change the alignment to 1. This needs to be fixed. > * lib/Transforms/Utils/InlineFunction.cpp - Uses getPrefTypeAlignment() to set the alignment of the alloca it introduces when a byval argument is inlined > * lib/Transforms/IPO/ConstantMerge.cpp - Uses getPreferredAlignment() to determine the alignment of the merged constant. Can't these just leave the alignment unset and let the code generator do its thing? > * lib/Transforms/Vectorize/BBVectorize.cpp - Depending on what options are set this pass avoids vectorization if it wo...

...ing later than it will change the alignment to 1. > This needs to be fixed. > > > * lib/Transforms/Utils/InlineFunction.cpp - Uses > > getPrefTypeAlignment() to set the alignment of the alloca it > > introduces when a byval argument is inlined > > * lib/Transforms/IPO/ConstantMerge.cpp - Uses > > getPreferredAlignment() to determine the alignment of the merged > > constant. > > Can't these just leave the alignment unset and let the code generator > do its thing? > > > * lib/Transforms/Vectorize/BBVectorize.cpp - Depending on what > >...

On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow (e.g. the maximum preferred alignment across all

On Oct 15, 2008, at 7:34 PM, Eli Friedman wrote: > This bug actually manifests itself in two places: one is > ConstantMerge, the other is the AsmPrinter. It's non-trivial to fix > because it's really a design bug: we assume that constant==mergeable, > which simply isn't true. There are a few different ways of fixing > this; however, I think the only real option is to add a new > "mergeable...

On 06/09/12 20:24, Chris Lattner wrote: > On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > >> I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

On Oct 15, 2008, at 6:58 AM, Tatu Vaajalahti wrote: >> Yes, but why do you think they should get a different address? I can >> understand that it is surprising that they do, but determining >> whether >> this is legal or not requires reading the language standard. >> Hopefully >> a language lawyer can chime in and say whether this transform is >>

On 15.10.2008, at 16.43, Duncan Sands wrote: >> True, but note that it is the address of a variable that is used, not >> the value. > > Yes, but why do you think they should get a different address? I can > understand that it is surprising that they do, but determining whether > this is legal or not requires reading the language standard. > Hopefully > a language

LLVMers, The LLVM 2.1 pre-release version2 is now available: http://llvm.org/prereleases/2.1/version2/ You can help test this pre-release by doing one of the following: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download llvm-2.1, llvm-test-2.1, and the llvm-gcc4.0 source.

...e/jo/Delta/llvm/test/Transforms/BlockPlacement/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/CodeExtractor/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/CondProp/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/ConstProp/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/ConstantMerge/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/CorrelatedExprs/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/DeadArgElim/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/DeadStoreElimination/dg.exp ... Running /home/jo/Delta/llvm/test/Transforms/DecomposeMultiDimRefs/dg.exp ....

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

...re registered. Index: lib/Transforms/IPO/CMakeLists.txt =================================================================== --- lib/Transforms/IPO/CMakeLists.txt (revision 237590) +++ lib/Transforms/IPO/CMakeLists.txt (working copy) @@ -3,6 +3,7 @@ add_llvm_library(LLVMipo BarrierNoopPass.cpp ConstantMerge.cpp DeadArgumentElimination.cpp + ElimAvailExtern.cpp ExtractGV.cpp FunctionAttrs.cpp GlobalDCE.cpp Index: lib/Transforms/IPO/ElimAvailExtern.cpp =================================================================== --- lib/Transforms/IPO/ElimAvailExtern.cpp (revision 0) +++ lib/Transfor...

Here's what's left on Linux (GCC 4.1.0), after all updates that went into the branch: Running /proj/llvm/build/../llvm/test/Regression/CFrontend/dg.exp ... FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-12- LargeAggregateCopy.c.tr: gccas: /proj/llvm/build/../llvm/lib/VMCore/Function.cpp:266: unsigned int llvm::Function::getIntrinsicID() const: Assertion `0 &&

On Mon, Feb 23, 2009 at 12:12 AM, Aaron Gray < aaronngray.lists at googlemail.com> wrote: > On Sun, Feb 22, 2009 at 11:15 PM, Anton Korobeynikov < > anton at korobeynikov.info> wrote: > >> >> Actually its [configure-stage3-intl] where its hanging. >> >> This can easily be due to inline FP math in the stdlib headers. For >> example - I had to

...cement/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/CodeExtractor/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/CondProp/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/ConstProp/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/ConstantMerge/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/DeadArgElim/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/DeadStoreElimination/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/GCSE/dg.exp ... Running /home/kooijman/src/llvm-trunk/test/Transforms/G...