search for: jpbonn

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

On 7/19/10 10:36 AM, Duncan Sands wrote: > Hi JP, > > >> 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

Here's a patch for WritingAnLLVMBackend.html that describes how instruction operand mapping works based on an IRC chat I had. Can someone review and apply it? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: write.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081120/c67a72f8/attachment.ksh>

I'd like to try running the LLVM test suite on a new backend. It appears the test suite only uses llvm-gcc and not clang. Is that correct? Can the test suite be configure to use clang? We haven't ported our target to llvm-gcc.

Our backend only does 32 bit loads. I noticed some loads were narrowed to 8 bits and then had to be reverted back to 32 bit loads. This patch prevents the initial lowering. I've only tested this on my backend. Can someone review and apply this or should I submit a bug? Index: CodeGen/SelectionDAG/TargetLowering.cpp =================================================================== ---

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

Our processor only does 32bit reads and writes to memory. Changing a byte requires a 32bit read, modify, 32bit write sequence to change the 8bit value in memory. How should this be handled? Do any of the other current backends do this?

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