similar to: [LLVMdev] question on assembler for systemz backend

Hello > 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: There are different instruction sets for z/System. Basically, you have to provide proper -march

Hi Anton, On 01/30/2011 12:44 PM, Anton Korobeynikov wrote: > Hello > >> 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: >

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

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

On 01/30/2011 02:09 PM, Anton Korobeynikov wrote: >> I'd still like to know if anyone has sucessfully assembled SystemZ generated >> assembly language with a binutils assembler, and if so, how. > Almost all testsuite passed ~ 1.5 years ago (with clang + gas). I > doubt anyone tried to assembler anything else after that time. > Lots of things have changed in 1.5 years with

> I'd still like to know if anyone has sucessfully assembled SystemZ generated > assembly language with a binutils assembler, and if so, how. Almost all testsuite passed ~ 1.5 years ago (with clang + gas). I doubt anyone tried to assembler anything else after that time. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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 All, I had some questions regarding the SystemZ implementation and missing instructions. I've been comparing the IBM z/Architecture Reference Summary (SA22-7871-08) to the output of "llvm-tblgen SystemZ.td -print-enums -class=Instruction" and noticed that there's 525 missing instructions. For example, if I look at instruction "M" (page 16) with opcode 0x5c (M

Richard Sandiford wrote: >I'd like to step down as code owner for the SystemZ port and nominate >Ulrich Weigand to take over. Sorry for not doing this sooner. I'd be happy to take over that role. Thanks for all your work on SystemZ, Richard! Bye, Ulrich

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

Hi, I have come across a major regression resulting after SLP vectorization (+18% on SystemZ, just for enabling SLP). This all relates to one particular very hot loop. Scalar code: %conv252 = zext i16 %110 to i64 %conv254 = zext i16 %111 to i64 %sub255 = sub nsw i64 %conv252, %conv254 ... repeated SLP output: %101 = zext <16 x i16> %100 to <16 x i64> %104 = zext

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:

Hi, SystemZ supports @llvm.ctlz.i64() natively with a single instruction (FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64. For some reason, this leads to unfolded additions of constants as shown below: This function: define i16 @fun(i16 %arg) {   %1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction

Hi LLVM Developers, I have a query about an LLVM error message that I'm encountering and I hope it's appropriate to post to this mailing list about it. Postgres can be built with LLVM-based JIT support. I find that when running on Linux (RHEL8) on IBM Z hardware, using LLVM8+, I'm seeing many instances of the following LLVM error message appearing in the Postgres server log: ORC

Hello, this set of patches adds platform-specific support to the base LLVM test suite. The first patch adds 290 new SystemZ CodeGen (.ll) tests. The second patch adds 582 new SystemZ MC assembler (.s) tests. The third patch adds the usual test suite config changes for a platform that supports MCJIT, but not the old JIT, modeled after existing changes for PPC64 and AARCH64. Overall, this test of

Hello, this set of patches adds Clang support for SystemZ. The first patch adds a new common code feature that allows platform code to request minimum alignment of global symbols. The background for this is that on System Z, the most efficient way to load addresses of global symbol is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction provides PC-relative addressing, but only

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

Hi, Attached is a patch I'm testing. It changes how "MachineFrameInfo::HasCalls" is calculated. Basically, the way it's calculated now is in PEI. And it only looks for frame adjustments (or inline ASM) to determine if the function has a call or not. This way is much more accurate and occurs much sooner. But it breaks this test:

Hi, we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag was incorrectly set while it actually shouldn't. The attached patch and test case triggers an assert in TwoAddress.  (bin/llc ./tc_TwoAddr_crash.ll