search for: archtyp

...er assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where ArchType would be passed to ELFObjectWriter and decoded into the correct 16-bit value. The way I see, the second approach has the advantage of being similar to the way OSType is currently handled by ELFObjectWriter but has the disadvantage of requiring backends to edit the ELFObjectWriter source file if th...

...'m working on LLDB and we have a bunch of code that is manually manipulating triples and doing a bunch of nasty stuff to account for the fact that llvm::Triple doesn't currently have a way to detect x86_64h. Is this something that llvm::Triple could be modified to support? Either as a new ArchType, or a new SubArchType? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/4e3f3ff1/attachment.html>

...b/Driver/ToolChains.h 2013-08-18 13:39:12.822210498 +0000 @@ -121,7 +121,7 @@ SmallVectorImpl<StringRef> &BiarchLibDirs, SmallVectorImpl<StringRef> &BiarchTripleAliases); - void ScanLibDirForGCCTriple(llvm::Triple::ArchType TargetArch, + void ScanLibDirForGCCTriple(llvm::Triple TargetTriple, const llvm::opt::ArgList &Args, const std::string &LibDir, StringRef CandidateTriple, --- ./tools/clang/lib/Driver/Tool...

...erTarget<Triple::sparc, /*HasJIT=*/false> X(TheSparcTarget, "sparc", "Sparc"); } The part I'm wondering about is Triple::sparc. If I'm writing a target for a different architecture, is it necessary for that architecture to have an entry in Triple's ArchType enumeration? The documentation doesn't seem to mention anything about adding members to the enumeration; is it an optional step? Making lots of small changes outside the specific source tree for the 65816 backend is something I'd prefer to avoid just at the moment, especially since it look...

...PU per se. It serves the same purpose as x86_64-* and powerpc64-*, which is to say it's associated with -m64, not -mcpu=v9 (although unsurprisingly -m64 does require a V9 or later CPU). I may be wrong, but I think the only distinction in ARM is between arm and thumb code, which do have distinct archtypes in Triple.h That said, I'm happy to change it however you like if you think it makes more sense, as long as we get distinct sparc-* and sparcv9-* triple strings in the end. > Also, please use the standard coding convention inside llvm-gcc patch. Oops, I messed the spacing on that one...

...// amdil: amd IL spir, // SPIR: standard portable IR for OpenCL 32-bit version - spir64 // SPIR: standard portable IR for OpenCL 64-bit version + spir64, // SPIR: standard portable IR for OpenCL 64-bit version + kalimba // Kalimba: generic kalimba }; - enum SubArchType { - NoSubArch, - - ARMSubArch_v8, - ARMSubArch_v7, - ARMSubArch_v7em, - ARMSubArch_v7m, - ARMSubArch_v7s, - ARMSubArch_v6, - ARMSubArch_v6m, - ARMSubArch_v6t2, - ARMSubArch_v5, - ARMSubArch_v5te, - ARMSubArch_v4t, - ARMSubArch_v4 - }; enum VendorType {...

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

...b/Driver/ToolChains.h 2013-08-18 13:39:12.822210498 +0000 @@ -121,7 +121,7 @@ SmallVectorImpl<StringRef> &BiarchLibDirs, SmallVectorImpl<StringRef> &BiarchTripleAliases); - void ScanLibDirForGCCTriple(llvm::Triple::ArchType TargetArch, + void ScanLibDirForGCCTriple(llvm::Triple TargetTriple, const llvm::opt::ArgList &Args, const std::string &LibDir, StringRef CandidateTriple, --- ./tools/clang/lib/Driver/Tool...

Hi Jonathan, This looks a bit odd. Any reason for the unknown->none conflating in this way? For most (all) of the ports unknown-elf works the same as none-elf. I'm also not sure if someone decided to have, arm-codesourcery-elf that this would still work with the patch. Thoughts? -eric On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson <amara.emerson at gmail.com> wrote: > Hi Jon,

...PU per se. It serves the same purpose as x86_64-* and powerpc64-*, which is to say it's associated with -m64, not -mcpu=v9 (although unsurprisingly -m64 does require a V9 or later CPU). I may be wrong, but I think the only distinction in ARM is between arm and thumb code, which do have distinct archtypes in Triple.h I mean for arm we have arm vs armv4, armv5, armv6, armv6t2, armv7-*. Same for thumb - thumb vs thumb2. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...that I had been using (within Swift’s Driver.cpp the following: static llvm::Triple computeTargetTriple(StringRef DefaultTargetTriple) { llvm::Triple triple = llvm::Triple(DefaultTargetTriple); // Canonicalization of all armv6 sub architectures to armv6 if (triple.getArch() == llvm::Triple::ArchType::arm) { if (triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6 || triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6m || triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6k || triple.getSubArch() == llvm::Triple::SubArchType::ARMS...

Le 16 déc. 2009 à 10:54, Mark Muir a écrit : > Hi all, > > I'm developing a custom back-end for an odd-ball architecture (but one that is still describable by LLVMTargetMachine). The toolchain that it will fit into doesn't have a linker as such, so I want to use assembly as the default output. I've got to the point of emitting working custom assembly for very simple C

..., so what do I need to do to ensure that I don't break anyone else who is running one of these systems and previously had a different default triple? On Tue, Aug 19, 2014 at 4:53 PM, Jim Grosbach <grosbach at apple.com> wrote: > Sure, go for it. It’d be a fairly natural fit for a SubArchType. > > > > > On Aug 19, 2014, at 2:44 PM, Zachary Turner <zturner at google.com> wrote: > > > > I'm working on LLDB and we have a bunch of code that is manually > manipulating triples and doing a bunch of nasty stuff to account for the > fact that llvm::Tri...

...:Level OL) > > - : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false), > > + : X86TargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, Triple(TT).getArch()) > > Think this is missing a "==Triple::x86_64” at the end, yes? Nah, I turned that parameter into a Triple::ArchType so that I can pass x86_16 as an option too. See the patch on llvm-commits which adds the x86_16 target. Currently working on a few codegen bugs with building the Linux kernel's 16-bit startup code with 'clang -m16'... -- dwmw2 -------------- next part -------------- A non-text attac...

Hi all, I'm developing a custom back-end for an odd-ball architecture (but one that is still describable by LLVMTargetMachine). The toolchain that it will fit into doesn't have a linker as such, so I want to use assembly as the default output. I've got to the point of emitting working custom assembly for very simple C programs (i.e. ones that don't rely on libraries). At the

> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > This part doesn't seem obvious from the direction the patches are going. > There will be no string representation of all options, as that would > be impossible, or at least, highly

...ed, Jul 9, 2014 at 11:39 AM, Jonathan Roelofs > <jonathan at codesourcery.com> wrote: >> >> On 7/9/14, 12:33 PM, Eric Christopher wrote: >>> Any reason why you deleted code that isn't related? >>> >>> -eric >>> >>>> - enum SubArchType { >>>> - NoSubArch, >>>> - >>>> - ARMSubArch_v8, >>>> - ARMSubArch_v7, >>>> - ARMSubArch_v7em, >>>> - ARMSubArch_v7m, >>>> - ARMSubArch_v7s, >>>> - ARMSubArch_v6, >>>> -...

I would prefer not to; they already live in a protected namespace, so there is no need to mangle them except to protect them from exuberant preprocessor defines, and this would be slightly out of style with other public uses of enumerations in LLVM. - Daniel On Tue, Aug 25, 2009 at 7:49 AM, Venkatraman Govindaraju<venkatra at cs.wisc.edu> wrote: > Instead of just upcasing them, can we

Hello, Nathan >   I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on

.... The majority of the typos were in comments and a few of them were in debug messages. I've also made another patch to the clang source base, it was sent to the cfe-dev mailing list earlier today. There were a few false positives found by codespell, the most common ones were: FromE -> from ArchType -> archetype isNT -> isn't DefInit -> definite I've gone through the diff and removed all of those false positives, and I've successfully built LLVM afterwards so everything should be OK. The patch was made using the official git mirror and was tested against current svn top...