similar to: [LLVMdev] New TargetSpec 'llvmnote'

On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > This leads to a number of problems in LLVM: > - we have a bunch of duplication > - we have confusion about what a triple is (normalized or not) > - no good way to tell if a triple is normalized > - no good, centralized way to reason about which triples are allowed and valid > - the MC assembler has to link in the entire X86

On Wed, Feb 23, 2011 at 01:43:35PM -0800, Dan Gohman wrote: > On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > > This leads to a number of problems in LLVM: > > - we have a bunch of duplication > > - we have confusion about what a triple is (normalized or not) > > - no good way to tell if a triple is normalized > > - no good, centralized way to reason about

On Feb 23, 2011, at 3:24 PM, Stephen Wilson wrote: >> >> On the other hand, if "Byte Order" makes sense to include, should >> other parts of targetdata be included? Pointer size seems the next >> most desirable -- endianness and pointer size would be sufficient for >> many elf tools, for example. However, the other parts of >> targetdata could

On Feb 23, 2011, at 2:47 AM, David Given wrote: > On 02/23/11 02:46, Chris Lattner wrote: > [...] >> Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. > > Can I put in a plea to have as much of LLVM as possible *not* require > knowledge of a single,

On Wed, Feb 23, 2011 at 2:46 AM, Chris Lattner <clattner at apple.com> wrote: > > There is recently a discussion on the LLDB list about how to deal with targets, and our current mismash of llvm::Triple and the various subclasses of TargetSubtarget leave a lot to be desired.  GNU target triples are really important as input devices to the compiler (users want to specify them) but they

On 23/02/11 19:26, Chris Lattner wrote: [...] > This request is completely orthogonal to the proposal. If you generate target independent LLVM IR, you don't have to put a triple into the IR. This isn't going to change. Unfortunately clang doesn't appear to be aware of this. It's forcing me to specify a triple (or at least, I haven't discovered a way of generating

On 02/23/11 02:46, Chris Lattner wrote: [...] > Remember that this isn't intended to be something users deal with, it's just an internal implementation detail of the compiler, debugger, nm implementation, etc. Can I put in a plea to have as much of LLVM as possible *not* require knowledge of a single, specific architecture to work? I have various things I would like to do that work on

This is about the target specification proposal described in http://nondot.org/sabre/LLVMNotes/TargetSpec.txt At the end of the year I spent a while on this, partly as a foot-wetting exercise for parts of LLVM I wouldn't otherwise look at. I did a partial implementation; enough to understand most of the issues (I hope) and get a clear idea of what would need to be done to phase it in. I

The simplest solution is probably to just break it out into its own library. -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130213/9ab171c0/attachment.html>

Hi, > Would it be OK to add "ELF" to Triple::EnvironmentType? It seems like a plausible choice since MachO is there. On the other hand, I'm not sure whether it makes sense to make it mutually exclusive with the other members of EnvironmentType (GNU, GNUEABI, EABI). EABI and GNUEABI imply ELF. GNU in practice does not need to imply ELF, but is used in the ARM world as "the

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

Ping, Apart from Anton's concerns (which I think are manageable) and Micah's support, I received no reply on this. Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here. The proposed "llvm::TargetSpec class"

On Sep 4, 2012, at 5:23 PM, Jim Grosbach <grosbach at apple.com> wrote: > Chris, are you OK with the below changes to the Triple? If at all possible, I'd like to keep the triple changes separate (separate patch series and separate discussion) from the other MCJIT changes. How dependent are the MCJIT improvements on the Triple changes? As you've noticed, Triple is not a

So does that mean that LLVM can't lower automatically to 8-bit values? I tried defining 8-bit pointers in the subtarget using "p:8:8:8" but it asserts at line 566 of TargetData.cpp in the default case of TargetData::getIntPtrType() Is it difficult to add 8-bit support? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

I wonder why AVX is not used automatically if available at the host machine. In contrast to that, SSE41 instructions (like pmulld) are automatically used if the host machine supports SSE41. E.g. $ cat avx.ll define void @_fun1(<8 x float>*, <8 x float>*) { _L1: %x = load <8 x float>* %0 %y = load <8 x float>* %1 %z = fadd <8 x float> %x, %y store

Hi all, There's been some controversies in the TargetTriple changes and I want to explain it better in the list (to a wider audience) and also propose my plans on how to support the ARM platform better, especially cross-compilation in Clang. All this discussion came as a spin-off of bug 8911 (http://llvm.org/bugs/show_bug.cgi?id=8957)... Today we have three major problems in cross-compiling

Chris, are you OK with the below changes to the Triple? -Jim On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > ping > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew > Sent: Tuesday, August 28, 2012 11:10 AM > To: Jim Grosbach; Pawel Bylica; Chris Lattner > Cc: llvmdev

On Tue, Jan 7, 2020 at 5:27 PM Eric Christopher <echristo at gmail.com> wrote: > > > On Tue, Jan 7, 2020 at 3:18 PM Daniel Sanders via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Jan 7, 2020, at 13:57, David Blaikie <dblaikie at gmail.com> wrote: >> >> >> >> On Mon, Jan 6, 2020 at 6:05 PM Daniel Sanders

> On Jan 7, 2020, at 13:57, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jan 6, 2020 at 6:05 PM Daniel Sanders <daniel_l_sanders at apple.com <mailto:daniel_l_sanders at apple.com>> wrote: > > >> On Jan 6, 2020, at 14:29, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:

Thank you Evan, I added the return Type::Int8Ty to the switch statement to get it to work. I don't know if this can have other consequences, I haven't yet verified if the generated Legalized DAG is correct though. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 3:23 PM To: