similar to: [LLVMdev] llvm-mc build fails

Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] llvm-mc build fails"

2009 Nov 02
0
[LLVMdev] llvm-mc build fails
John Myers <atomicdog.jwm at gmail.com> writes: > I'm looking for some pointers on how to troubleshoot this problem. I'm > trying to write a backend for the AVR. > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a
2004 Jun 09
2
[LLVMdev] X86 Frame info question
The X86 backend has this code: X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) : .... FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), That is, it uses "4" as local area offset. Based on prior discussion this should mean that the local area starts and address ESP+4. Is this really true? On X86 stack grows down, so
2004 Jun 09
0
[LLVMdev] X86 Frame info question
On Wed, 9 Jun 2004, Vladimir Prus wrote: > > The X86 backend has this code: > > X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL) > : .... > FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4), > > That is, it uses "4" as local area offset. Based on prior discussion this > should mean that the local
2011 May 06
0
[LLVMdev] Question about linking llvm-mc when porting a new backend
Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:
2017 Dec 20
6
[GlobalISel] gen-global-isel failed to work
Hi Leslie, On 20 December 2017 at 10:51, Leslie Zhai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry, I am apprentice of lowRISC, and meet new bug when porting GlobalISel > to RISCV target > https://github.com/xiangzhai/llvm/commit/b3f91ea54d9fee0ef7e73a32c6b8456bbe252811 > > > In file included from >
2005 Feb 17
0
[LLVMdev] LLVM under MS VC++ 2005
I have got the latest CVS release of LLVM. And built the Win32 MS VC++ 2003 port with modifications for MS VC++ 2005. Do bear in mind the Visual Studio ports are by no means complete, and are on going. Microsoft Visual Studio 2005 Beta (codename Whidbey) can be got from Microsoft Beta program nearly for free; the cost of postage from :-
2005 Feb 17
2
[LLVMdev] LLVM under MS VC++ 2005
I missed two files from the LLVM source code proper. These need reviewing and commiting. They are trivial changes that should not influence any other builds. Basically these functions are missing a return statement which Visual Studio 2005 Beta flags as an error rather than as a warning. I have put in dummy constructors in return statements to allow CodeGen and Target libraries to build. The
2004 Jun 08
1
[LLVMdev] TargetFrameInfo: what's local area offset
Chris Lattner wrote: > On Mon, 7 Jun 2004, Vladimir Prus wrote: > > The TargetFrameInfo, amoung other things, specifies "local area offset" > > -- which, as comment say, is: > > > > the offset of the local area from the stack pointer on entrance to a > > function. > > > > The question is -- what's local area? Is this the first stack
2012 Apr 17
2
[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass
With reference to the previous query, I think, i miscalculated the offset, just recalculating. 1. without instruction combining coupling member variable, is at:   %struct._FRAME_DATA* %2, i32 0, i32 5   where "%2" is defined as:   %arrayidx3 = getelementptr inbounds i16* %Data, i32 1024, !dbg !446   %2 = bitcast i16* %arrayidx3 to %struct._FRAME_DATA*, !dbg !446 i.e. at 5 offset in
2012 Apr 19
2
[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass
I think, finally, I want to conclude on this.   The problem I see is that if I comment the case for "simplificaiton of bitcast to gep of original struct in instruction combining", wherein there is a case for if the offset by which GEP moves the pointer is non-zero.   If I disable this code, then structure elements size, I get is
2009 Nov 16
4
[LLVMdev] SAFECode Source Code Released
Török Edwin wrote: > [snip] > > I applied the attached patch to make it compile on my box (Debian > x86_64), only to find out that x86_64 is not supported :( > This architecture is not supported by the pool allocator! > Aborted > Thanks for the patch. What options do I give to the patch command to apply it to the source code? Although there's no documentation about
2004 Jun 07
2
[LLVMdev] TargetFrameInfo: what's local area offset
The TargetFrameInfo, amoung other things, specifies "local area offset" -- which, as comment say, is: the offset of the local area from the stack pointer on entrance to a function. The question is -- what's local area? Is this the first stack location which can be used by function for allocating its own variables? - Volodya
2004 Jun 07
0
[LLVMdev] TargetFrameInfo: what's local area offset
On Mon, 7 Jun 2004, Vladimir Prus wrote: > > The TargetFrameInfo, amoung other things, specifies "local area offset" -- > which, as comment say, is: > > the offset of the local area from the stack pointer on entrance to a > function. > > The question is -- what's local area? Is this the first stack location which > can be used by function for
2012 Apr 19
0
[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass
Hi Pankaj, are you testing this on valid bitcode? The bitcode you sent me did not pass the verifier, i.e. was not valid. Optimizers can be expected to do strange and wrong things if passed invalid bitcode. That is not a bug in LLVM: it is user error if a user doesn't use valid bitcode. Ciao, Duncan. > I think, finally, I want to conclude on this. > The problem I see is that if I
2009 Sep 05
0
[LLVMdev] 2.6 pre-release1 ready for testing
On 2009-08-31 08:50, Tanya Lattner wrote: > LLVMers, > > 2.6 pre-release1 is ready to be tested by the community. > http://llvm.org/prereleases/2.6/ > Hi Tanya, Here are the results for x86_64 Linux (Debian unstable): > You will notice that we have quite a few pre-compiled binaries (of > both clang and llvm-gcc). We have identified several bugs that will be > fixed in
2009 Apr 08
4
[LLVMdev] What is the state of LLVM's ARM backend
Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm
2009 Apr 08
2
[LLVMdev] What is the state of LLVM's ARM backend
Duncan Sands skrev: > Hi Xerxes, > > >> 4. softfloat related errors >> http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ >> example: >> >> root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc >>
2012 Apr 18
0
[LLVMdev] Issue with GetElementPtrInst in Instruction Combining pass
Hi All,   Further exploring the problem I could find that, there is a address offset calculation problem, with the GEP bitcast handling code in instruction combining. Below is table which shows address offset calculation for the struct elements (described earlier).   Type Variable Actual Size(in bytes) pass fail llvm2.9 Address(pass) Size-pass (in bytes) Address (fail) Size -fail (in bytes) with
2010 Mar 18
0
[LLVMdev] How to link LLVMCore.a into a custom pass that is fed to opt
Hey all, I need to use C bindings in a pass that I am authoring (specifically, I want to use the OCaml bindings that are tied to the C bindings to author the pass). However, this requires that I link in LLVMCore to provide said bindings to my library. From what I've read, there is a known issue with linking LLVMCore into a module that is fed to opt. Namely, you get the following assertion:
2004 Oct 18
3
[LLVMdev] Fix for non-standard variable length array + Visual C X86 specific code
Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to