similar to: Subtarget Initialization in <ARCH>TargetMachine constructor

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.

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

I'm working on a target based on the MIPS target, and when I copy f64 values into 32 bit registers for calling functions, I need the operation to work on a of 32 bit registers (because the language I'm translating to isn't actually mips). I've been looking at how to do this, but I haven't been able to figure it out. Since the Mips target code is still really close to mine,

Ryan, I don't think I fully understand the problem you described, but please see the comments below. Hope this helps you solve the problem. On Sat, Oct 6, 2012 at 3:18 PM, ryan baird <ryanrbaird at gmail.com> wrote: > I'm working on a target based on the MIPS target, and when I copy f64 > values into 32 bit registers for calling functions, I need the operation to > work

Updated patch is attached. Note this is just a work-in-progress patch and I plan to address the feedback comments later if this patch is in the right direction. This is how the command line options are parsed and used by the backend passes: 1. Tools such as clang and llc call cl::ParseCommandLineOptions. Any of the options that should be written to the bitcode as function or module attributes

On Fri, Dec 5, 2014 at 2:40 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed Dec 03 2014 at 11:39:23 AM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> On Tue, Dec 2, 2014 at 4:38 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> >>> >>> >>> On Tue Dec 02 2014 at 4:31:43 PM Akira Hatanaka

On Wed, Nov 19, 2014 at 3:28 PM, Eric Christopher <echristo at gmail.com> wrote: > So my general concern here is that lots of command line options that don't > need to be or shouldn't be IR level constructs become oddly named string > options. It's bad enough that we're doing that with the target cpu and > target feature string let alone the rest of it. > >

On Tue, Dec 2, 2014 at 4:38 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue Dec 02 2014 at 4:31:43 PM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> On Tue, Dec 2, 2014 at 3:21 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> >>> On Mon Dec 01 2014 at 4:22:15 PM Bob Wilson <bob.wilson at apple.com>

> On Nov 19, 2014, at 4:52 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Wed Nov 19 2014 at 4:39:42 PM Akira Hatanaka <ahatanak at gmail.com <mailto:ahatanak at gmail.com>> wrote: > On Wed, Nov 19, 2014 at 3:28 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > So my general concern here is

Thanks for your feedback, Eric. I still think we may be talking past each other a little bit, but rather than delving further into the details right now, I’ve suggested to Akira that he look into how we should handle other kinds of options. I’m hoping that as we look at more of them, we will gain some insight into the approach that we want to take here. This patch really only deals with the easy

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

These two subclasses of X86TargetMachine are basically identical. The *only* thing that's different is the constructor. And that *only* differs in the is64Bit argument that it passes to the X86TargetMachine constructor. Replacing the hard-coded 'true' or 'false' with 'Triple(TT).getArch()==Triple::x86_64' makes them *actually* identical. Can we just ditch the

On Tue, Dec 2, 2014 at 3:21 PM, Eric Christopher <echristo at gmail.com> wrote: > On Mon Dec 01 2014 at 4:22:15 PM Bob Wilson <bob.wilson at apple.com> wrote: > >> Thanks for your feedback, Eric. >> >> I still think we may be talking past each other a little bit, but rather >> than >> > > Might be, sorry if so :( > > >> delving

> On Nov 14, 2014, at 2:44 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > +chrisb > >> On 2014-Nov-13, at 16:33, Akira Hatanaka <ahatanak at gmail.com> wrote: >> >> I'm working on fixing PR21471, which is about embedding codegen command line options into the bitcode as function or module-level attributes so that they don't get

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

For those targets supported by LLVM, you can get their TargetData by creating TargetMachine first (take X86 as example): ==== BEGIN CODE SNIPPET ==== const std::string TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const

I've been investigating what is needed to ensure command line options are passed to the backend codegen passes during LTO and enable compiling different functions in a module with different command line options (see the links below for previous discussions). http://thread.gmane.org/gmane.comp.compilers.llvm.devel/78855 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/80456 The command

Hi, I've prepared patches for both LLVM and Clang to change the datalayout for R600. This may seem like a bold move, but I think it is warranted. R600/SI is a strange architecture in that it uses 64bit pointers but does not support 64 bit arithmetic except for load/store operations that roughly map onto getelementptr. The current datalayout for r600 includes n32:64, which is odd

I think we have located the revision which fixes this regression: r206094 (or commit 6bb00df in llvm-mirror on GitHub). I have attached a patch which can be applied to the current release_34 branch (tested against the release_34 branch in llvm-mirror). With this patch the attached reg-alloc-test.ll file doesn't fail with the "LLVM ERROR: ran out of registers during register