similar to: [LLVMdev] Proposal: Move host CPU auto-detection out of the TargetMachine

Eric Christopher <echristo at gmail.com> writes: > I'm not a huge fan of this because then you get to decide on a default > for all the ports, but I can understand if people want to move this > way to reduce uncertainty. FWIW, since it's one of the three targets Jim mentioned, -march=z10 is the obvious default for SystemZ. On the other hand, I think it's good to run

Hi Hal, I only just noticed that about a year ago, Jim removed CPU auto-detection for the X86 target: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-April/071991.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140407/212676.html >Currently the X86 backend does CPU auto-detection and subtarget feature >detection when the TargetMachine is created if no explicit CPU was

We already decide on a default. For these three targets is “whatever the user is running on.” For all the other targets it’s something the backend selects. I’m proposing we, as you say, remove the uncertainty and have the default always be the same from one run to the next even (especially) when those runs are on different machines. For X86, there’s two options, the “generic” target that backend

On Thu, Apr 10, 2014 at 7:41 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Apr 10, 2014 at 6:32 PM, Jim Grosbach <grosbach at apple.com> wrote: >> >> It's very important that a run of "llc" on one machine produce the same >> output on two heterogenous machines given the same input and command lines*. >> That's not true right now,

Hello, I'd like to propose the addition of a new SystemZ backend to the LLVM and Clang code base. We're interested in this for the same reason we've been interested in the PowerPC back-end recently: to enable packages in upcoming enterprise Linux distributions that need LLVM support (e.g. 3D desktop support via llvmpipe). Now, I understand that a SystemZ backend used to be part of

> I'd like to propose the addition of a new SystemZ backend to the LLVM and > Clang code base. We're interested in this for the same reason we've been > interested in the PowerPC back-end recently: to enable packages in upcoming > enterprise Linux distributions that need LLVM support (e.g. 3D desktop > support via llvmpipe). Cool! > - focus on feature completeness

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.

Hal Finkel <hfinkel at anl.gov> wrote on 23.03.2015 19:42:06: > > >Attached are draft patches that do this for X86. Similar but smaller > > >cleanups can also be done for SystemZ and PowerPC if it’s agreed > > >this is a good idea. > > > > However, this was then never implemented for SystemZ and PowerPC. > > Should we do so as well? > >

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,

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

Dear everyone, The in-progress release notes for 3.7 [1,2] make it look like we didn't do very much over the past six months. Obviously that's not the case at all, so let's get them in shape! If you've been thinking "I should probably add this to the release notes at some point", now is the time :-) I have a list below of changes that might be worth mentioning. I

On Fri, Apr 11, 2014 at 3:58 PM, Jim Grosbach <grosbach at apple.com> wrote: > > Now, one additional thing we could do (outside the scope of this proposal) > is also implement a fuzzer of some kind to look for target tests that don’t > have an explicit arch/feature/whatever setting on the RUN line and run it > with all available -mcpu= values and see if it still passes (which

On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Are there reasons why we might not want to do this? Other options we should > consider? It does make the TargetMachine -> TargetIRAnalysis path less abstract, but given that all targets have the same pattern of instantiating a TargetIRAnalysis with a Function->TargetTransformInfo hook, the abstraction does

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

Hi, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is

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

Many thanks! On Fri, Aug 14, 2015 at 6:47 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > LLVM: > > LLVM no longer attempts to automatically detect the > current host CPU when invoked natively. > > LLVM now supports all thread-local storage models on SystemZ. > (Previous releases would support only the local-exec TLS model.) > > LLVM now uses the POPCNT

What assembler are people using with the SystemZ backend? I am trying to assemble the output of the SystemZ backend with the GNU binutils assembler (build with --target=s390x-linux). I get errors when assembling instructions with literals that are negatives. For example, the test case test/CodeGen/SystemZ/01-RetImm.ll gives errors: $ s390x-as 01-RetImm.s 01-RetImm.s: Assembler messages:

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

On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > ----- Original Message ----- > > > > From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent: