similar to: Whither/whether -mtune support?

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 all, As of r232885 I've removed the argument-less TargetMachine::getSubtarget and TargetMachine::getSubtargetImpl. For the targets that aren't completely independent of this I've gone ahead and left a non-virtual version of the function in the target specific TargetMachine. What this means in practice is that those targets can only use a bare getSubtarget call in their target

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

To continue the discussion I started last year (see the link below) on embedding command-line options in bitcode, I came up with a plan to improve the way the backend changes UnsafeFPMath on a per-function basis. The code in trunk currently resets TargetOptions::UnsafeFPMath at the beginning of SelectionDAGISel::runOnMachineFunction to enable compiling one function with “unsafe-fp-math=true” and

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,

I've been trying to understand the current state of subtargets and subtarget features in LLVM. It seems like the presence of "target-cpu" and "target-features" attributes on IR functions are currently intended to take precedence over the module-level (TargetMachine) versions. See X86TargetMachine::getSubtargetImpl for an example of this. However, this feels like it is

On Sat, May 7, 2011 at 4:17 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, Justin > > Thansk, but I have a little concern though. I saw Chiou mentioned the > compatibility issue of PTX on the mailing list. > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html > > In my PTX.td patch, > > def FeaturePTX23 : SubtargetFeature<"ptx23",

Hi, Justin Thansk, but I have a little concern though. I saw Chiou mentioned the compatibility issue of PTX on the mailing list. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html In my PTX.td patch, def FeaturePTX23 : SubtargetFeature<"ptx23", "PTXVersion", PTX_VERSION_2_3", "Use PTX Language Version

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

Hi Chris, Chris Lattner wrote: >> 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. >> However, Linux and Darwin do not have the same set >> of non-callee saved registers. I don't know how to make the if(isDarwin) test >> in here >> > > Take a look at ARM/ARMRegisterInfo.td for an example of this I tried to define Defs just

Hello, I'm implementing a port of LLVM for PowerPC VLE. It's a compressed instruction set similar to mips16 and ARM Thumb. Instruction encoding (VLE/non-vle) is selected for a given memory region by an attribute in a memory area descriptor. Targets supporting this that I know of are all bare-metal (so powerpc-none-elf). I'm trying to implement ELF support right now. VLE ELF files

David Blaikie <dblaikie at gmail.com> 於 2020年1月6日 週一 下午2:23寫道： > If this is something that can vary per file in a compilation and resolve > correctly when one object file is built with one ABI and another object > file is built with a different ABI (that seems to be antithetical to the > concept of "ABI" Though) - then it should be a subtarget feature. > > ABI is

Why does GCC produce faster code using "-march=pentium2 -mtune=pentium4" on a Pentium 4 chip versus plain -march=pentium4? Try it... CPUTYPE=pentium2 CFLAGS+= -mtune=pentium4 COPTFLAGS+= -mtune=pentium4 -- BSD Podcasts @ http://bsdtalk.blogspot.com/

Hi all. There are two steps in LTO codegen so the problem is how to pass ABI info into LTO code generator. The easier way is pass -target-abi via option to LTO codegen, but there is linking issue when linking two bitcodes generated by different -mabi option. (see https://reviews.llvm.org/D71387#1792169) Usually the ABI info for a file is derived from target triple, mcpu or -mabi, but in RISC-V,

On Fri, 2 Feb 2007, Nicolas Geoffray wrote: > I have almost completed the implementation of a linux/ppc backend in llvm. Cool! > There were a few things to modify in > lib/Target/PowerPC with a lot of "if (!isDarwin)". Some meta comments: 1. Please don't change PPC -> llvmPPC. I assume that you did this because PPC is a #define in some system header. Please

Which options are you seeing that cause the largest difference, and on which targets? As Chandler mentioned there has been a large amount of variation in x86 targets, and there are certain optimizations that can be done, on say a Pentium (scheduling instructions which are pairable and non-dependent so the U and V pipelines are saturated without contention, for example) that don't make sense

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 ?

I have been doing some benchmarking on x86 using llvm 2.9 with the llvm-gcc 4.2 front end. I noticed that the -march and -mtune options make a significant positive difference in x86-32 mode but hardly make any difference in x86-64 mode. The small difference that I am measuring when the target is x86-64 could easily be random variation, while for the x86-32 target I am measuring a huge difference

What's the purpose of the TargetSubtarget class? It appears the only users of getSubtarget are in the target-specific code, where the abstraction is superfluous. Is it just a way to encourage targets to follow a nice pattern of keeping subtarget state in a separate class, or are there grand plans? Dan -- Dan Gohman, Cray Inc.

Thanks very much Eric for taking the time to carefully explain this to me. So if I am the author of the backend for a new processor technology, or willing to modernise my existing implementation, you would recommend that the ‘-mcpu’ option is deprecated and probably best not used at all, or perhaps just as a synonym for ‘-march + -mtune’? The first part of the target triple guides the