similar to: [LLVMdev] Code ownership for SystemZ port

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

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? > >

Hello, this set of patches adds SystemZ support to base LLVM. This is split up into three patches just to simplify review; they should be committed as a single change if approved. The first patch adds SystemZ support to the configure logic and support for the systemz Triple. This ought to be straightfoward. The second patch adds changes to LLVM common code required to support the SystemZ ELF

Hans Wennborg wrote: >Dear testers, > >8.0.0-rc4 was just tagged from the release_80 branch at r355690. I've tested the current branch on SystemZ without problems. I noticed I forgot to send a ReleaseNotes updates, sorry. If there's still time, here's a list of the major user-visible changes: (See attached file: systemz-releasenotes.diff) Mit freundlichen Gruessen / Best

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

Hi, Two days ago, the test suite started failing. Initially there were hundreds of failing tests; now only seven remain. They appear to be related to SystemZ. Here's the last failed test: ******************** FAIL: LLVM :: MC/Disassembler/SystemZ/unmapped.txt (11484 of 14435) ******************** TEST 'LLVM :: MC/Disassembler/SystemZ/unmapped.txt' FAILED ******************** Script:

Csaba Raduly <rcsaba at gmail.com> wrote: > error: no disassembler for target s390x--linux-gnu The SystemZ disassembler was only recently added. To process major changes to the source tree like the addition of a completely new component, it seems to be necessary to explicitly re-run configure (or sometimes even remove the build directory completely and start from scratch). I've

Andrew Kaylor wrote: >In general, the current "strict FP" handling stops at instruction >selection. At the MachineIR level we don't currently have a mechanism >to prevent inappropriate optimizations based on floating point >constraints, or indeed to convey such constraints to the backend. >Implicit register use modeling may provide some restriction on some

Hello, as discussed here in more detail: https://reviews.llvm.org/D81583 the introduction of the C++20 [[no_unique_address]] attribute exposes an ABI issue on platforms that require special handling for structs/classes that are "equivalent" to a single floating-point member (or in some cases, a "homogeneous" set of floating-point members). This is because we can now for the

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

> On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we’re

On Tue, Jan 09, 2018 at 06:53:51PM +0000, Kaylor, Andrew via cfe-dev wrote: > I think we're going to need to create a new mechanism to communicate > strict FP modes to the backend. I think we need to avoid doing anything > that will require re-inventing or duplicating all of the pattern > matching that goes on in instruction selection (which is the reason >

I think we're going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we're currently dropping that information). I'm out of my depth on this transition, but I think maybe we could

Hi, It has been discovered recently that it is needed for the SystemZ backend to add super-regs to the callee saved regs list like: def CSR_SystemZ : CalleeSavedRegs<(add (sequence "R%dD", 6, 15), - (sequence "F%dD", 8, 15))>; + [R6Q, R8Q, R10Q, R12Q, R14Q], +

>The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into >each other (which sounds disastrous), you're going to need to communicate strictness on an >instruction-by-instruction basis. If the backend wants to handle that by

On 9 Jan 2018 22:55, "John McCall via llvm-dev" <llvm-dev at lists.llvm.org> wrote: On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: >The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; >unless you're going to prevent functions that use stricter/laxer FP rules from being inlined

Bill Wendling <wendling at apple.com> wrote: > Please test out these sources and create bug reports for any > problems you encounter (http://llvm.org/bugs/) --- and please CC me > on those bug reports. The RC looks good on SystemZ; all projects/test-suite tests pass. There are still two failing tests in the regression suite: LLVM :: DebugInfo/namespace.ll This was already

Hello, as of Jul 9, the LNT build bot on SystemZ shows red. The problem occurs in the "setup lit" test, which fails due to: Processing dependencies for LNT==0.4.2.dev0 Searching for typing Reading https://pypi.org/simple/typing/ Downloading

Hi, I found with the help of the optimization remarks a loop that could not be vectorized, but if loop distribution was enabled this may happen, which it in fact did with a very significant benchmark improvement (~25%). I tried (on SystemZ) to enable this pass, and found that it only affected a handful of files on SPEC. This means I could enable this without worrying about any regressions on

Hi, On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < rsandifo at linux.vnet.ibm.com> wrote: > İsmail Dönmez <ismail at donmez.ws> writes: > > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm > > 3.4rc1: > > Hmm, I don't see this locally. Just to rule out one possibility, > which compiler are you using to build? Do you see the