similar to: [LLVMdev] Running all the backends over test/CodeGen/Generic

Hi, Compilation of the the following very simple file crashes with --march=ia64 on my x86 machine. ; ModuleID = 'bugpoint-reduced-simplified.bc' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-pc-linux-gnu" @x = weak global [8 x i32] zeroinitializer, align

Hello, Roman > llc: /opt/llvm/lib/Target/ELFTargetAsmInfo.cpp:133: const > llvm::Section* llvm::ELFTargetAsmInfo::MergeableStringSection(const > llvm::GlobalVariable*) const: Assertion `getCStringSection() && > "Should have string section prefix"' failed. > > Is it a bug in the ia64 backend? In general - yes. Please file a PR. I should introduce a fallback

On Feb 8, 2007, at 10:46 AM, Lauro Ramos Venancio wrote: > I'm facing a problem with functions arguments. ARM EABI defines that > 8-bytes arguments must be 8-bytes aligned. For example: > > void @f(i32 %a, i64 %b) > > ARM EABI: > r0 <- %a > r2,r3 <- %b Ok. I suppose this makes it easier to use 64 bit store instructions. > > Darwin: > r0 <- %a >

On Fri, Mar 7, 2008 at 8:28 PM, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: > When using mips-unknown-linux-gnu as a cross-compiler, the llvm Mips > backend is called by cc1 and with that you get llvm bytecode defined > relative to the Mips ABI. That was my intention. The PSP has a 32-bit MIPS (derived) CPU. What I don't know is if that triple is the right one

> > Yes, you need to override both LowerArguments and LowerCallTo. All of > the current targets / abi's use the default implementation in > SelectionDAGISel.cpp But I guess ARM EABI will be the first. :-) As > far as I can see, this is the only clean way to do it. I expect the > ARM EABI specific implementation will be quite a bit simpler than the > default implementation

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

I am ok with adding an attribute but don't like to add two of them as you've described. I don't think you need the "sequential piece ID" to deal with this issue, no? You just need a little extra bookkeeping in the target lowering code. Alternatively, you can use a "original alignment" attribute (i.e. alignment of unexpanded argument). That would be a 5-bit

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

Dan Gohman wrote: > Hello, > > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets,

On M68k the return value is passed register d0, unless it is a pointer then it is returned in register a0 (shadowed in d0 for some targets in GCC). For calling conventions compatible with Turbo/Pure C the first two pointes would also go in a0-a1, and the first three integers in d0-d2 (This is not supported by official GCC as of now). Simply subclassing CCIf and check ValVT or LocVT like this does

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example

On Apr 23, 2009, at 8:09 PM, Dan Gohman wrote: > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major > change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary

What is the difference between these two functions? The header file for TargetLowering class says that LowerArguments must be implemented, but only the Sparc and IA64 backends implement them. X86, PowerPC and CellSPU implement LowerFORMAL_ARGUMENTS, but I can find a setOperationAction that states that they should be lowered. Can someone please explain this for me? Thanks, Micah Villmow

I wish to assure you that I have not forgotten this task, nor failed to start on it, but I cannot give even a rough estimate on when it will be completed. It occurs to me that all declarations of a function pointer, and all bitcasts to a function pointer, could possibly refer to a function whose signature must be altered by this fix. Is the function signature relevant to the SelectionDAG

Hi, While working on adding newlib to my backend I hit the following assert : Assertion failed: BestRC && "Couldn't find the register class", file TargetRegisterInfo.cpp, line 112 The following llvm causes this : define void @specialBreak(i8* %out) nounwind { entry: %out.addr = alloca i8*, align 4 store i8* %out, i8** %out.addr, align 4 %0 = load i8** %out.addr,

I'm facing a problem with functions arguments. ARM EABI defines that 8-bytes arguments must be 8-bytes aligned. For example: void @f(i32 %a, i64 %b) ARM EABI: r0 <- %a r2,r3 <- %b Darwin: r0 <- %a r1,r2 <- %b void @g(i32 %a, i32 %b, i32 %c) ARM EABI or Darwin: r0 <- %a r1 <- %b r2 <- %c The problem is: I can't differ a i64 argument of two i32 arguments in

Hello, Pekka > 12) getSectionForFunction(*f) to f->getSection() This is not a correct substitution. Function::getSection() returns section set on function explicitely, getSectionForFunction() calculated desired section name, where function should be emitted into (for example, unique function name for linkonce stuff). getSectionForFunction() was replaced with universal

Hello, Attached is a patch which significantly reworks how calls, incoming arguments, and outgoing return values are lowered. It's a major change, affecting all targets, so I'm looking for feedback on the approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, and to facilitate future refactoring and feature work.

Hi everyone, It seems variable arguments is not support by mips backend in llvm-2.6. int func(int i, ...) { return 0; } llvm-gcc func.c -emit-llvm -c -O3 -o func.bc llc func.bc -relocation-model=static -march=mips -O0 -o func.s Command llc fails: llc:SelectionDAGBuilder.cpp:6440:void llvm::SelectionDAGISel::LowerArguments( llvm::BasicBlock):Assertion 'Invals.size() ==

Hi, I have an assert firing due to PickNodeToScheduleBottomUp(): 1. having a CallResource in use pushing an interference of current SUnit. 2. having no more SUnits in the AvailableQueue 3. The only interference being the SUnit that just failed due to a Call Resource. 4. An attempt to duplicate this node which has the 'Call Resource' as a physical register. Thus the call