search for: grimley

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 it means ".balign 16", and on some it means ".p2align 16", which would mean ".balign 65536" if

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 h...

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

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 =...

On Tue, 14 Dec 2010 10:55:09 -0000 "Edmund Grimley-Evans" <Edmund.Grimley-Evans at arm.com> wrote: > 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&...

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 -float-abi=hard < %s | FileCheck %s >> >> define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { >> ; C...

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

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

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 > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's goin...

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

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)': /arm/scratch/egrimley/llvm.svn/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1880: sorry, unimplement...

You forgot to reply to the list. Also CC'ing LLVMdev. On 3/12/10 1:41 PM, Edmund Grimley-Evans wrote: >>> clang -cc1 -triple thumbv7-eabi -O3 -target-cpu cortex-a8 t.c >>> -emit-llvm-bc >>> llc t.bc ... -view-legalize-dags >> You just answered your own question :). That will work quite nicely >> actually. > > Maybe it would if I knew exactl...

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

...Patel wrote: > 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 -float-abi=hard < %s | FileCheck %s >>> >>> define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64>...

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.

> 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 >

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

...one at a time. LLVM also declares standard module/function passes on include/llvm/Support/StandardPasses.h. Have a look and see if that's what you want. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Edmund Grimley-Evans > Sent: 16 July 2010 11:25 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] How to visualise Clang optimisation phases > > When I'm trying to understand how or why the back end does > something I've found the -view-* options to llc to be useful. > It's not...

When I'm trying to understand how or why the back end does something I've found the -view-* options to llc to be useful. It's not ideal, because "clang" doesn't take those options, so I have to invoke first "clang" and then "llc", and sometimes that combination gives different final code from invoking just "clang", but usually I can construct