similar to: [LLVMdev] Retargetting llvm to a simplified X86_64 architecture

Hey all, I am trying to implement a new subtarget for the X86 target that has only 64 bit registers and instructions and a very minimal ISA excluding any FPU instructions etc. I have made the required changes to the instructions such that all the instructions that I don't wish to use have a required<> clause that precludes them from being utilised when compiling for this subtarget.

Hey all, I am trying to implement a subtarget for the X86 architecture that only has 64 bit Registers. While running LLC on the IR for a very simple program, llc fails on an assertion that says it doesn't know how to promote ISD::FRAMEINDEX. I've tried to look for why how to promote the frameindex which is stored in a i32 variable to an i64 variable but can't seem to find where

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

Some problems... (or I'm missing something...) 1) asmwriternum seems to be not supported... scons: Building targets ... d:/home/arathorn/sandbox/llvm/tblgen.exe -gen-asm-writer -asmwriternum=1 -I llvm\lib\Target\X86 -o tablegen_includes\X86GenIntelAsmWriter.inc llvm\lib\Target\X86\X86.td llvm\lib\Target\X86\X86InstrInfo.td llvm\lib\Target\X86\X86RegisterInfo.td llvm\lib\Target\Target.td

Hey Everyone, I understood this a little differently (well, I do have direct contact with Sumeeth given that we both work in the same lab). Allow me to try and explain his proposal. We are trying to optimise out instructions from a program (JIT-compiled OS Kernels or JIT-compiled Web Server code) during run time and we have this hypothesis that some of the decisions are best taken by the

On Apr 9, 2009, at 11:11 AMPDT, Aaron Gray wrote: > On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info > > wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it > bespoke C++ code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling

Could someone please apply this patch to the Win32 support so that Morten and Jeff can handle the recent changes? I can't do it because I"m on the road with only email access. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: Reid Spencer <reid at x10sys.com> > Subject: Updated LLVM Visual Studio project files > Date: Thu,

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

On Thu, Apr 9, 2009 at 4:34 PM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > Hello, Aaron > > > How/where are function prologs and epilogs generated, is it bespoke C++ > code > > or TableGen generated ? > > > > If someone could point me in the right direction please. > Calling convention is really-really far from prologue/epilogue emission :)

On Aug 11, 2013, at 4:14 AM, "Nuno Lopes" <nunoplopes at sapo.pt> wrote: >> This sounds promising. But we have some requirements that textbook rewriting systems can't handle: >> >> - Expressions are DAGs, not trees. >> - Targets can add custom rewriting rules and override standard rules. >> - Rules will have predicates. Some predicates are static

Hello, I m working towards backend. Here i need to define vector load and stores for 64 i32 elements. so in x86instrinfo.td i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))],

Hi! I want to use LLVM for my own "pet" programming language compiler as a backend. Currently it generates C code, but I am not satisfied with this approach as generating high-level C (with proper type declarations!) is horrible. So here are my questions/problems with LLVM: 1.) Are there operations that add, sub, mul integers with overflow checking? How much work would it be to add

On Sep 11, 2009, at 3:31 PM, David Greene wrote: > Attached is a patch to print asm comments for spill information. > We've discussed the mechanisms before but I wanted to run the > patch by everyone before I start to commit pieces. Some thoughts: The general approach to enhancing CreateStackObject and adding MachineInstr::AsmPrinterFlags seems fine to me! The testcase should

Hi Eli, Thanks for the response I have one question inline. Regards, Ben [...] > The main problem that I have hit is regarding the use of CL register in the > shift instructions. The problem is that ATT syntax states that it should be > referenced as "%cl" while Intel says just "cl" but these references occur in > X86InstInfo.td and this means that it is shared

Hi Fellows, I’ve recently encountered a problem with X86 segment registers. I created a new calling convention and for some purposes I have to use a segment register for one of the argument passed by the caller. I found out that in X86RegisterInfo.td, SEGMENT_REG was defined there, and I directly grabbed the one I need into my calling convention in X86CallingConv.td. However, I got an error

Hi Arnold and Anton, Sorry I have been ignoring your emails on this topic. It's an important task and I really need sometime to think about it (and talk to Chris about it!) But this has been an especially hectic week. I am also going to vacation soon so I am not sure when I would get around to it. If Chris has time, I am sure he has lots to say on this topic. :-) Otherwise, please

Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file

Thanks Kevin for the reply. I got the point now :) On 10 Apr 2015 00:18, "Smith, Kevin B" <kevin.b.smith at intel.com> wrote: > For x86_64 ABI, a minimum feature set of SSE2 is required. > > > > Kevin > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *suyog sarda > *Sent:* Thursday, April 09,

On Tue, 12 Oct 2004, Paolo Invernizzi wrote: > Hi all, > I cannot figure out why is named GenRegisterInfo.h.inc and not > GenRegisterInfo.inc ... > Is it for a dependency problem? I'm not sure what you're saying here. In the X86 backend, for example, we generate both X86GenRegisterInfo.h.inc and X86GenRegisterInfo.inc. The former is #included into X86RegisterInfo.h and the

Thanks, Alex. See my comments below. On Wed, Aug 23, 2017 at 12:59 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 22 August 2017 at 23:39, Y Song via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, > > Hi Yonghong. > >> I found some different discrepancy on how Subtarget is created >> between some arch specific TargetMachine constructor.