similar to: [LLVMdev] [RFC/PATCH][3/4] New SystemZ backend:Clang changes

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

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

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

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

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:

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

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

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

> 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

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

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, 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:

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

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

> On 2016-Jul-11, at 09:05, Ulrich Weigand <ulrich.weigand at de.ibm.com> wrote: > > uweigand accepted this revision. > uweigand added a comment. > This revision is now accepted and ready to land. > > I'll defer to your expertise on that. Patch looks good to me. > > I guess I'm not fully familiar with some of the C++ language details here. Would you

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