search for: 7c175e

I just tried cmake for the first time and it mostly worked. I had been using autotools to configure. With cmake configure environment when I try to do: make TESTSUITE=CodeGen/mblaze check it runs the whole test suite. Under autotools it would just run the mblaze tests. Is there an equivalent command in a camke configured environment or is this broken? I know nothing about cmake so I'm

2011/6/9 llvmjp <jpbonn-keyword-llvm.7c175e at corniceresearch.com>: > make TESTSUITE=CodeGen/mblaze check Are they useful to you? $ bin/llvm-lit -sv -jN test/CodeGen/MBlaze $ bin/llvm-lit -sv -jN /path/to/source/llvm/test/CodeGen/MBlaze/hogehoge.ll ...Takumi

Does llvm-ld support linker scripts or have a mechanism for specifying where sections should be loaded? It's unclear to me what the -native option really does. Is llvm-ld intended to be a full replacement for ld? Thanks, JP

Can someone explain how the condition code is passed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue

The following code compiles for Sparc prior to version 119382 but causes a llc to hang in version 119382 and later. I glanced at it but haven't figure it out yet. I figure I'd ping the list to see if it's an obvious fix to someone else. define void @test(i16 %di, i32 %L_num, i32 %tmp1, i16* %P) { %X = shl i16 %di, 1 ; <i16> [#uses=1] %tmp28 = shl

I noticed SDTypeProfile is commonly used with -1 for the number of operands, as in: def SDT_SystemZCall : SDTypeProfile<0, -1, [SDTCisPtrTy<0>]>; What does this do?

It appears llc gives preference to the default target datalayout whereas opt gives preference to the module datalayout. Is there a reason they behave differently? From llc.cpp: // Add the target data from the target machine, if it exists, or the module. if (const TargetData *TD = Target.getTargetData()) PM.add(new TargetData(*TD)); else PM.add(new TargetData(&mod));

I suspect this is a straight forward problem so I thought I'd ask. I'm developing a new backend. I recently updated from the LLVM repository and now my output assembly is branching to labels/blocks that have been removed. It had been working fine two weeks ago. What looks suspicious is the following message: TryTailMergeBlocks: BB#1, BB#3, BB#4 Looking for common tails of

I'm running into the same problem mentioned here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-February/038027.html but I think the underlying problem is different from what he mentions. The stack on the processor I'm working on is aligned to 4 bytes per the ABI but stack objects can be created with higher alignments (datalayout of i64:32:32). As an example, I'm running into a

DAGCombiner::ReduceLoadWidth() does the following: /// ReduceLoadWidth - If the result of a wider load is shifted to right of N /// bits and then truncated to a narrower type and where N is a multiple /// of number of bits of the narrower type, transform it to a narrower load /// from address + N / num of bits of new type. If the result is to be /// extended, also fold the extension to form a