similar to: [LLVMdev] llvm::Triple support for haswell-enabled x86_64

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

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

On Tue, Aug 19, 2014 at 5:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Note that it’s not exactly equivalent to enabling -march=core-avx2. It’s > really close, but not 100% the same. What is the difference? and why? It seems really confusing to have this divergence, or to be unable to replicate the *exact* behavior of this (very weird, and IMO *bad* triple) with the standard

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

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

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); //

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

> On Aug 20, 2014, at 9:37 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Aug 19, 2014 at 10:37 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Tue, Aug 19, 2014 at 5:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Note that it’s not exactly equivalent to enabling -march=core-avx2. It’s really close, but not 100% the same. >

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

> On Aug 21, 2014, at 12:23 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > On 20 Aug 2014, at 18:03, Jim Grosbach <grosbach at apple.com> wrote: > >> There’s a few more subtleties, but that’s a reasonable analogy. While the sub-arch is related to a -march= setting, it is very definitely not the same thing. It’s not even just the sub-arch. Consider,

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

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

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,

> On 2015 Mar 30, at 10:11, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Mar 30, 2015 at 9:52 AM Eric Christopher <echristo at gmail.com> wrote: > From PR18808 I said a few things and that I was going to redirect to the mailing list for further discussion. So here we are, go. > > 1) Whether or not to allow changing of

Hi, I'm building LLVM on Mac OS 10.10 and I'm having trouble making LTO work. The system linker dumps the following information when I executed "ld -v" @(#)PROGRAM:ld PROJECT:ld64-241.9 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7m armv7em LTO support using: LLVM version 3.4.2 which tells me that it is correctly pointing to the LLVM

On Jan 12, 2015, at 2:45 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 10 January 2015 at 17:43, Rahman Lavaee <r.lavaee at gmail.com> wrote: >> Hi, >> I'm building LLVM on Mac OS 10.10 and I'm having trouble making LTO work. >> The system linker dumps the following information when I executed "ld -v" >> >>

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

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

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 Dean, For me the build is still broken: -- Builtin supported architectures: i386;x86_64;x86_64h CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): add_library cannot create target "RTXRay.test.osx" because another target with the same name already exists. The existing target is a static library created in source directory