similar to: [LLVMdev] Building out-of-tree targets

I believe we'd need LLVMBuild.txt even in autoconf build - for bunch of autogenerated stuff, e.g. list of all asmprinters / asmparsers / InitializeAllTargetInfos, etc., since targets are not autoregistered anymore. On Mon, Mar 9, 2015 at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Neil, > > Weird, I'd think the cmake build should probably do something

The following configure/make is failing on the top of tree llvm/clang sources: ./configure --enable-optimized --disable-assertions --enable-targets=x86,x86_64,arm --build=x86_64-apple-darwin10 ./make clang-only llvm[2]: Compiling Tool.cpp for Release build In file included from /Volumes/work/gclayton/Documents/src/llvm/include/llvm/Target/TargetSelect.h:38, from

On Thu, Jul 16, 2009 at 11:43 AM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > 2009/7/16 Daniel Dunbar <daniel at zuster.org> >> >> On Thu, Jul 16, 2009 at 10:04 AM, Aaron >> Gray<aaronngray.lists at googlemail.com> wrote: >> > 2009/7/16 Chris Lattner <clattner at apple.com> >> >> Whats Daniels approach, does he have any

Hi Jean-Daniel, My fault, I'm sure, but I don't see the problem yet. Is it possible your version of llvm/Config/AsmPrinters.def has X86 listed twice? - Daniel On Mon, Aug 2, 2010 at 12:43 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After I try making a clean build and got the following error: > > llvm[3]: Compiling EDDisassembler.cpp for

Hello, After I try making a clean build and got the following error: llvm[3]: Compiling EDDisassembler.cpp for Release build In file included from /llvm/include/llvm/Target/TargetSelect.h:38, from /llvm/lib/MC/MCDisassembler/EDDisassembler.cpp:37: /llvm/stage1/include/llvm/Config/AsmPrinters.def: In function ‘void LLVMInitializeX86TargetAsmPrinter()’:

As the question asks, I'm having some trouble using initializeAllTargets(). I have a CMakeLists that uses: llvm_map_components_to_libnames(LLVM_LIBS ... AllTargetsAsmParsers AllTargetsAsmPrinters AllTargetsDescs AllTargetsInfos ...) However, even with these, when I try to compile my program, I get linker errors: CMakeFiles/sxhc.dir/src/main.cpp.o: In function

> If we don't want to do that, I think we should try to add the new > constructors while keeping the old ones around, and then delete the > old constructors once clang is updated. Yes, this would probably be the best. To make clang build I just hacked the constructors in the patch I posted, but they should really just forward to the new ones. >> *) Please name the most general

Hi all, If you have an out of tree target and use the IfConverter be aware of a new API call "getPredictationCost“ that you might want to implement: After commit r191671: IfConverter: Use TargetSchedule for instruction latencies For targets that have instruction itineraries this means no change. Targets that move over to the new schedule model will be able to use the new

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

2009/7/16 Daniel Dunbar <daniel at zuster.org> > On Thu, Jul 16, 2009 at 10:04 AM, Aaron > Gray<aaronngray.lists at googlemail.com> wrote: > > 2009/7/16 Chris Lattner <clattner at apple.com> > >> Whats Daniels approach, does he have any online documentation or code, > do > >> you have an email address so I may talk to him. > >> >

On Thu, Jul 16, 2009 at 10:04 AM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > 2009/7/16 Chris Lattner <clattner at apple.com> >> Whats Daniels approach, does he have any online documentation or code, do >> you have an email address so I may talk to him. >> >> Take a look at how asmprinters work >> in include/llvm/Target/TargetRegistry.h .

On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > HI > Did you run the static constructor and destructor? How did you make your process symbols visible to ORC jit? Yes. It's the constructor that generates the undefined symbol error. We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process symbols. > Could you

You can add symbols from Archieve via StaticLibrarySearchGenerator. But it is added recently though On Tue, 27 Aug 2019 at 21:02, Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > I tried it, but I can't able to reproduce it. > > Test Program: > #include <fstream> > int main() > { > std::ifstream stream1, stream2; >

Hi, I will soon be committing a change to MachineFrameInfo::CreateStackObject that removes the "bool MayNeedSP" parameter. This API change is part of larger patch that re-works stack layout passes to use analysis from the StackProtector pass to layout StackProtected objects (http://llvm-reviews.chandlerc.com/D2158). Out of tree targets will need to update their usage accordingly. The

Hi, I'm about to commit a change to TargetLowering::getSetCCResultType, adding an LLVMContext & argument to it ( http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130506/174067.html). Out of tree targets will need to be updated to build, but it's a simple change. You only need to add the new first argument it. - Matt Arsenault -------------- next part --------------

I've been attempting to get to get Shared Folders and ACL's to work under dovecot 1.0rc17. Unfortunately, I've run into some problems (many have already been mentioned on the list), specifically the problem where folder-specific ACL files are not found (and I will not use Global ACL's due to the 100% probability of cross-namespace mailbox name conflicts). My namespace

Hi, I need an advice how to support both big and little endian MIPS targets in the new LLD ELF design and escape code duplication. MIPS 32-bit big and little endian targets are very similar and differ in read/write functions. There are some options how to support both but I cannot make the best choice. 1. Make MipsTargetInfo a class template. Use the template's argument to select read/write

Hi, attached is a patch to improve including targets other than X86 in CMake MSVC builds. When adding libs to link, rather than always using LLVMX86CodeGen and LLVMX86AsmPrinter, it grabs the correct ones. It also adds "force-link-ints" to the various TargetMachine cpp files, as well as X86AsmPrinter and PPCAsmPrinter. These are needed to be able to encourage the Win32 linker to

On Aug 19, 2009, at 4:39 PM, Sean Callanan wrote: > thanks for your comments. I'll respond to them individually. I've > attached a new revision of the patch that addresses them. Patch > built and tested against SVN 79487, with the additional attached fix > that fixes an Intel table bug. Thanks Sean, comments below. Are you sure you attached the updated patch? I

Thanks for the review! Comments inline; new patch attached. On Thu, Jun 21, 2012 at 8:40 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> If we don't want to do that, I think we should try to add the new >> constructors while keeping the old ones around, and then delete the >> old constructors once clang is updated. > > Yes, this would probably be