search for: archtypes

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter 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

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::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

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

I'm having a go at writing an LLVM backend for the WDC 65816. The documentation page on writing an LLVM backend<http://llvm.org/docs/WritingAnLLVMBackend.html>gives this example of target registration: extern "C" void LLVMInitializeSparcTargetInfo() { RegisterTarget<Triple::sparc, /*HasJIT=*/false> X(TheSparcTarget, "sparc",

...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,...

Hello LLVMdev!! Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead. My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to

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

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

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

Hi all. I’ve been working with Swift on ARMv6 and v7. While working with ARMv6 on linux, I noticed that my arm architecture canonicalization code didn’t produce the expected result. The code that I had been using (within Swift’s Driver.cpp the following: static llvm::Triple computeTargetTriple(StringRef DefaultTargetTriple) { llvm::Triple triple = llvm::Triple(DefaultTargetTriple); //

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

Sounds good, I'll give it a try sooner or later. I've never messed with triples, so is there anything I need to be aware of so I don't break any code on other platforms? In particular, I want llvm::sys::getDefaultTargetTriple() to return me this new haswell-aware triple, so what do I need to do to ensure that I don't break anyone else who is running one of these systems and

On Mon, 2014-01-06 at 14:23 -0800, Jim Grosbach wrote: > Hi David, > > AFAIK, the answer is basically “because it’s always been that way.” I > seem to recall there were some things that were different (data layout > string and such), but that could also be parameterized if it hasn’t > been already by the recent refactorings, I suppose. It is *all* now parameterized. The classes

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

Eric Christopher wrote: > On Wed, 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, >>>> -

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

Hi, I've made the attached patch that fixes several typos on the LLVM source code, they were found and fixed by the codespell tool (which was announced at http://www.politreco.com/2011/04/announce-codespell-1-0/ ). 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