similar to: [LLVMdev] [llvm-commits] Major regressions

On Sat, 2007-04-21 at 18:28 -0500, Christopher Lamb wrote: > On Apr 21, 2007, at 6:12 PM, Reid Spencer wrote: > > > On Sat, 2007-04-21 at 18:07 -0500, Christopher Lamb wrote: > >> I'm getting a regression after my fixes that's coming from > >> getABIAlignment not finding an alignment to use for a <float x1> > >> type, > >> is this a

Hola LLVMers, One of the corner-case features of the Hydra language I work on are Boolean vectors of length 2, 3, or 4 which I've been representing as either <2 x i1> or <4 x i1>. I picked up the latest LLVM about a week back and since then I've been unable to compile things using this construct. It asserts in TargetData::getAlignmentInfo since it doesn't have

Duncan, could this be related to your recent work? Chuck, this is unlikely to be a x86 specific problem. Please file a bug. Thanks! Evan On Dec 6, 2007, at 5:06 PM, Chuck Rose III wrote: > Hola LLVMers, > > One of the corner-case features of the Hydra language I work on are > Boolean vectors of length 2, 3, or 4 which I’ve been representing as > either <2 x i1> or

Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in

Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder

Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,

On Apr 1, 2007, at 3:11 AM, Chris Lattner wrote: > On Sun, 1 Apr 2007, Christopher Lamb wrote: >> Also I wanted to clear something up about the meaning of the >> alignment >> attribute. My thinking is that this indicates over/under alignment >> with >> respect to natural alignment for the type. This is to say in the >> Load/Store >> instruction

On Mon, 22 May 2017, Dr. ERDI Gergo wrote: > Actually, tracking down the sequence of function calls, it turns out that '8' > is ultimately coming from the following call in DataLayout::getAlignment: > > getAlignmentInfo(AGGREGATE_ALIGN, 0, abi_or_pref, Ty); > > this seems to return 8 with the following datalayout string: > >

On Sun, 1 Apr 2007, Christopher Lamb wrote: > Also I wanted to clear something up about the meaning of the alignment > attribute. My thinking is that this indicates over/under alignment with > respect to natural alignment for the type. This is to say in the Load/Store > instruction classes the default alignment value will be zero, meaning natural > alignment for the given type.

On 2008-07-21, at 14:42, Matthijs Kooijman wrote: > Hi Mon Ping, > >> As you also mentioned, I don't like that we pass a reference to >> TargetData with the AddrspacesDescriptor and that we have a static >> default implementation store in the class. It is unclear to me if >> this is the right class for it as not as it describes the structure >> and

On Feb 1, 2010, at 11:06 AM, Garrison Venn wrote: > Is there a way using llvm::TargetData to determine the alignment of what would be equivalent > to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the > target platform so that I know what the max alignment of an address returned by malloc(...) will > be. Not currently. The alignment

Hi Gordon, > TargetData is a concrete class, part of the middle-end. It describes > parts of the the target's ABI. It allows target-independent passes to > do things like decide whether x[1] and ((char *) x)[4] alias. This is > possible without actually linking with the code generator for the > relevant target. TargetData can be encoded in the LLVM IR, e.g. target

Is there a way using llvm::TargetData to determine the alignment of what would be equivalent to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the target platform so that I know what the max alignment of an address returned by malloc(...) will be. Thanks in advance Garrison

On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > If the TargetData pass isn't registered in the global registry, > getPassInfo() returns null. > > Now when you add a TargetData pass, it winds up in ImmutablePasses. > Any search through ImmutablePasses assumes that getPassInfo() for > every member returns something other than null.

>> Anyway, my present plan of attack is to have a "-defaulttarget" option >> with "none", "host", or a target string.  If -defaulttarget is not >> specified, the behavior of "opt" will be the same as it is presently. >> The defaulttarget will be overridden by the Module's target data if it >> has some.  "none"

On Oct 21, 2009, at 9:31 AM, Kenneth Uildriks wrote: > On Wed, Oct 21, 2009 at 10:59 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> If the TargetData pass isn't registered in the global registry, >> getPassInfo() returns null. >> >> Now when you add a TargetData pass, it winds up in ImmutablePasses. >> Any search through ImmutablePasses

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

Having a ModulePass that requires a FunctionPass that in turn requires another ModulePass results in an assertion being fired. Is this expected behavior (that seems to be undocumented), or a bug? Specifically, the following code will emit the assertion: [VMCore/PassManager.cpp:1597: virtual void llvm::ModulePass::assignPassManager(llvm::PMStack&, llvm::PassManagerType): Assertion