similar to: [LLVMdev] ambiguity of .align

Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed

2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures

I'm getting a lot of this from make check: g++: unrecognized option `-Qunused-arguments' This presumably comes from commit 94666 (test/LLVMC/ExternOptions.td and other files). That option is specific to clang, isn't it? Should %compile_cxx be picking up clang instead of my system's g++? -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and

According to the few tests I did, .ll.gz is more compact: 1.00 LLVM bitcode (.bc) 0.80 Gzipped LLVM bitcode (.bc.gz) 4.13 LLVM assembly (.ll) 0.68 Gzipped LLVM assembly (.ll.gz) However, there's not much in it, considering that a stripped native binary is about 0.40 on the same scale. So, seeing as projects such as PNaCl want to send LLVM bitcode over the network, are there any proposed

I think this test case demonstrates it: ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { ; CHECK: vadd.i64 %y = add <4 x i64> %a, %b ret <4 x i64> %y } (I hope I got that right.) -- IMPORTANT NOTICE: The contents of this email and any

The log message for revision 122213 says: > Change the X86 backend to stop using the evil ADDC/ADDE/SUBC/SUBE nodes (which > their carry depenedencies with MVT::Flag operands) and use clean and beautiful > EFLAGS dependences instead. (MVT::Flag has since been renamed to MVT::Glue.) That revision made bug 8404 go away. Am I right in thinking that one of the problems with MVT::Glue is

I don't think this has ever worked. Evan On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > I think this test case demonstrates it: > > ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s > > define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { > ; CHECK: vadd.i64 > %y = add <4

Could some kind soul point me at the documentation, or the appropriate header file, or an example of the best way to write a pass that modifies the IR? Suppose, for example, that I wanted to replace every call to the intrinsic i1 with a call to i2 followed by a call to i3: i1(X) -> i3(i2(X)) I'm currently playing around with a class that inherits from FunctionPass and InstVisitor and I

It used to. I just checked with r90370. deep On Thu, May 13, 2010 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > I don't think this has ever worked. > > Evan > > On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > >> I think this test case demonstrates it: >> >> ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi

> Having a look at clang's source, you can find in > "lib/CodeGen/BackendUtil.cpp" the functions where clang builds the > passes to emit code. The optimization passes used are there and you can > simulate them via the "opt" utility, by running each pass one at a time. > LLVM also declares standard module/function passes on >

hi, i was trying to enable the mmx code on mac os x. to get to that point one has to replace some inline assembler code: .balign 16 -> .p2align 4 and replace .rept .. .endr with #defines. but to makes things more complicated apple's GAS does not support movsx instructions and thus the following line does not work: " movsx %%di, %%edi \n\t" [ more details at

Here's a patch to fix some bugs in my code, plus a header file I probably forget to send in before. * Missing header file charset.h. It's not needed outside vorbis-tools/share, so I think it can live there. * There was a minor bug in the UTF-8 decoder utf8_mbtowc(). * I've added some more tests in charset_test.c in an attempt to convince myself that there aren't any more bugs.

With a modified copy of LLVM (so it's probably my fault) I'm getting an assertion failure because isTwoAddrUse (in TwoAddressInstructionPass.cpp) is being called with a MachineInstr MI such that MI.getNumOperands() is 2, but MI.getDesc().getNumOperands() is 5. The assertion fails when that function calls MI.getOperand(2). My question is: is isTwoAddrUse doing the right thing here? static

Using GCC 3.4.6 20060404 (Red Hat 3.4.6-11) I've had this problem with the ALWAYS_INLINE directive in SelectionDAGISel.cpp: /arm/scratch/egrimley/llvm.svn/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In function `bool CheckChildType(const unsigned char*, unsigned int&, llvm::SDValue, const llvm::TargetLowering&, unsigned int)':

My experimental code calls DAG.getNode to construct a unary node with a flag result. Unfortunately the argument turns out to be constant, so lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2332 calls VT.getSizeInBits on the flag type, which isSimple(), so we call V.getSizeInBits at ValueTypes.h:560 and fail at ValueTypes.h:240: clang: .../include/llvm/CodeGen/ValueTypes.h:240: unsigned int

On Mon, 2010-01-25 at 17:56, Rafael Espindola wrote: > On what architecture did you got the error? We have AlignmentIsInBytes > in MCAsmInfo for that. It is probably wrong for your architecture. Thanks. This was on ARM, and this one-line diff against r94535 made it work for me. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be

hello vorlon, got notified of your patch, will apply next days upstream unless some critiques are voiced on ml. thanks. -- maks ----- Forwarded message from Steve Langasek <steve.langasek at canonical.com> ----- Date: Wed, 16 Feb 2011 22:05:42 -0000 From: Steve Langasek <steve.langasek at canonical.com> Subject: [Bug 527720] Re: thumb2 porting issues identified: klibc uses

Hi all, I noticed that the static local variable(internal global in .bc) is not aligned in ARM ELF(use MC(-filetype=obj)). Then I found that the alignment information is lost at: lib/CodeGen/AsmPrinter/AsmPrinter.cpp:316 if (MAI->hasLCOMMDirective()) { // .lcomm _foo, 42 OutStreamer.EmitLocalCommonSymbol(GVSym, Size); return; } MCStreamer::EmitLocalCommonSymbol have

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Hi, Can you please file a bug and Cc me directly on it? I'll go take a look soon. Thanks -jason On Wed, Jul 20, 2011 at 9:53 AM, TDYa127 <a127a127 at gmail.com> wrote: > Hi all, > > I noticed that the static local variable(internal global in .bc) is > not aligned in ARM ELF(use MC(-filetype=obj)). > Then I found that the alignment information is lost at: >