• Home
Name Date Size #Lines LOC

..--

AsmParser/03-May-2024-1,3401,071

Disassembler/03-May-2024-511404

InstPrinter/03-May-2024-342262

MCTargetDesc/03-May-2024-1,058783

TargetInfo/03-May-2024-5236

CMakeLists.txtD03-May-20241.3 KiB4540

LLVMBuild.txtD03-May-20241 KiB3632

README.txtD03-May-20243.9 KiB160108

SystemZ.hD03-May-20248.1 KiB202131

SystemZ.tdD03-May-20242.8 KiB8060

SystemZAsmPrinter.cppD03-May-202421.2 KiB657531

SystemZAsmPrinter.hD03-May-20241.9 KiB5839

SystemZCallingConv.cppD03-May-2024682 229

SystemZCallingConv.hD03-May-20244.6 KiB13177

SystemZCallingConv.tdD03-May-20245.9 KiB132107

SystemZConstantPoolValue.cppD03-May-20241.7 KiB5337

SystemZConstantPoolValue.hD03-May-20241.7 KiB5932

SystemZElimCompare.cppD03-May-202421.8 KiB642456

SystemZExpandPseudo.cppD03-May-20245.4 KiB154101

SystemZFeatures.tdD03-May-20249.1 KiB271225

SystemZFrameLowering.cppD03-May-202420 KiB547391

SystemZFrameLowering.hD03-May-20242.4 KiB6040

SystemZHazardRecognizer.cppD03-May-202414.2 KiB460315

SystemZHazardRecognizer.hD03-May-20245.8 KiB16358

SystemZISelDAGToDAG.cppD03-May-202465.7 KiB1,8501,284

SystemZISelLowering.cppD03-May-2024279.1 KiB7,2905,421

SystemZISelLowering.hD03-May-202425.5 KiB654359

SystemZInstrBuilder.hD03-May-20241.7 KiB4726

SystemZInstrDFP.tdD03-May-20248.9 KiB232193

SystemZInstrFP.tdD03-May-202424.2 KiB558463

SystemZInstrFormats.tdD03-May-2024168.8 KiB4,8914,223

SystemZInstrHFP.tdD03-May-20249.4 KiB241198

SystemZInstrInfo.cppD03-May-202466.1 KiB1,8931,476

SystemZInstrInfo.hD03-May-202413.2 KiB327192

SystemZInstrInfo.tdD03-May-202498.2 KiB2,2051,895

SystemZInstrSystem.tdD03-May-202417.2 KiB524405

SystemZInstrVector.tdD03-May-202473.4 KiB1,5561,352

SystemZLDCleanup.cppD03-May-20244.9 KiB14789

SystemZLongBranch.cppD03-May-202416.1 KiB473301

SystemZMCInstLower.cppD03-May-20243.1 KiB10478

SystemZMCInstLower.hD03-May-20241.2 KiB4524

SystemZMachineFunctionInfo.cppD03-May-2024480 183

SystemZMachineFunctionInfo.hD03-May-20243.1 KiB8041

SystemZMachineScheduler.cppD03-May-20248.7 KiB261162

SystemZMachineScheduler.hD03-May-20245 KiB15773

SystemZOperands.tdD03-May-202423.5 KiB625527

SystemZOperators.tdD03-May-202443.7 KiB829767

SystemZPatterns.tdD03-May-20248.5 KiB177159

SystemZProcessors.tdD03-May-20241.6 KiB3931

SystemZRegisterInfo.cppD03-May-202412.7 KiB326243

SystemZRegisterInfo.hD03-May-20243.4 KiB9560

SystemZRegisterInfo.tdD03-May-202412 KiB322274

SystemZSchedule.tdD03-May-20242 KiB6553

SystemZScheduleZ13.tdD03-May-202472.1 KiB1,5501,256

SystemZScheduleZ14.tdD03-May-202477.7 KiB1,6391,340

SystemZScheduleZ196.tdD03-May-202455.5 KiB1,236994

SystemZScheduleZEC12.tdD03-May-202457.3 KiB1,2811,027

SystemZSelectionDAGInfo.cppD03-May-202412.8 KiB275191

SystemZSelectionDAGInfo.hD03-May-20243.1 KiB7547

SystemZShortenInst.cppD03-May-20249.7 KiB326234

SystemZSubtarget.cppD03-May-20242.9 KiB7346

SystemZSubtarget.hD03-May-20247.8 KiB219120

SystemZTDC.cppD03-May-202413.1 KiB383265

SystemZTargetMachine.cppD03-May-20249.3 KiB264140

SystemZTargetMachine.hD03-May-20241.9 KiB5932

SystemZTargetTransformInfo.cppD03-May-202431.9 KiB909622

SystemZTargetTransformInfo.hD03-May-20243.6 KiB10063

README.txt

1//===---------------------------------------------------------------------===//
2// Random notes about and ideas for the SystemZ backend.
3//===---------------------------------------------------------------------===//
4
5The initial backend is deliberately restricted to z10.  We should add support
6for later architectures at some point.
7
8--
9
10If an inline asm ties an i32 "r" result to an i64 input, the input
11will be treated as an i32, leaving the upper bits uninitialised.
12For example:
13
14define void @f4(i32 *%dst) {
15  %val = call i32 asm "blah $0", "=r,0" (i64 103)
16  store i32 %val, i32 *%dst
17  ret void
18}
19
20from CodeGen/SystemZ/asm-09.ll will use LHI rather than LGHI.
21to load 103.  This seems to be a general target-independent problem.
22
23--
24
25The tuning of the choice between LOAD ADDRESS (LA) and addition in
26SystemZISelDAGToDAG.cpp is suspect.  It should be tweaked based on
27performance measurements.
28
29--
30
31There is no scheduling support.
32
33--
34
35We don't use the BRANCH ON INDEX instructions.
36
37--
38
39We only use MVC, XC and CLC for constant-length block operations.
40We could extend them to variable-length operations too,
41using EXECUTE RELATIVE LONG.
42
43MVCIN, MVCLE and CLCLE may be worthwhile too.
44
45--
46
47We don't use CUSE or the TRANSLATE family of instructions for string
48operations.  The TRANSLATE ones are probably more difficult to exploit.
49
50--
51
52We don't take full advantage of builtins like fabsl because the calling
53conventions require f128s to be returned by invisible reference.
54
55--
56
57ADD LOGICAL WITH SIGNED IMMEDIATE could be useful when we need to
58produce a carry.  SUBTRACT LOGICAL IMMEDIATE could be useful when we
59need to produce a borrow.  (Note that there are no memory forms of
60ADD LOGICAL WITH CARRY and SUBTRACT LOGICAL WITH BORROW, so the high
61part of 128-bit memory operations would probably need to be done
62via a register.)
63
64--
65
66We don't use ICM, STCM, or CLM.
67
68--
69
70We don't use ADD (LOGICAL) HIGH, SUBTRACT (LOGICAL) HIGH,
71or COMPARE (LOGICAL) HIGH yet.
72
73--
74
75DAGCombiner doesn't yet fold truncations of extended loads.  Functions like:
76
77    unsigned long f (unsigned long x, unsigned short *y)
78    {
79      return (x << 32) | *y;
80    }
81
82therefore end up as:
83
84        sllg    %r2, %r2, 32
85        llgh    %r0, 0(%r3)
86        lr      %r2, %r0
87        br      %r14
88
89but truncating the load would give:
90
91        sllg    %r2, %r2, 32
92        lh      %r2, 0(%r3)
93        br      %r14
94
95--
96
97Functions like:
98
99define i64 @f1(i64 %a) {
100  %and = and i64 %a, 1
101  ret i64 %and
102}
103
104ought to be implemented as:
105
106        lhi     %r0, 1
107        ngr     %r2, %r0
108        br      %r14
109
110but two-address optimizations reverse the order of the AND and force:
111
112        lhi     %r0, 1
113        ngr     %r0, %r2
114        lgr     %r2, %r0
115        br      %r14
116
117CodeGen/SystemZ/and-04.ll has several examples of this.
118
119--
120
121Out-of-range displacements are usually handled by loading the full
122address into a register.  In many cases it would be better to create
123an anchor point instead.  E.g. for:
124
125define void @f4a(i128 *%aptr, i64 %base) {
126  %addr = add i64 %base, 524288
127  %bptr = inttoptr i64 %addr to i128 *
128  %a = load volatile i128 *%aptr
129  %b = load i128 *%bptr
130  %add = add i128 %a, %b
131  store i128 %add, i128 *%aptr
132  ret void
133}
134
135(from CodeGen/SystemZ/int-add-08.ll) we load %base+524288 and %base+524296
136into separate registers, rather than using %base+524288 as a base for both.
137
138--
139
140Dynamic stack allocations round the size to 8 bytes and then allocate
141that rounded amount.  It would be simpler to subtract the unrounded
142size from the copy of the stack pointer and then align the result.
143See CodeGen/SystemZ/alloca-01.ll for an example.
144
145--
146
147If needed, we can support 16-byte atomics using LPQ, STPQ and CSDG.
148
149--
150
151We might want to model all access registers and use them to spill
15232-bit values.
153
154--
155
156We might want to use the 'overflow' condition of eg. AR to support
157llvm.sadd.with.overflow.i32 and related instructions - the generated code
158for signed overflow check is currently quite bad.  This would improve
159the results of using -ftrapv.
160