[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Bugfix in getDemandedSrcElements(). (#88623) (PR #95463)
uweigand wrote: It is not a regression, but a codegen wrong-code bug that can trigger based on random source code changes. Given that fact, and the fact the fix is very simple and "obviously correct", I do think this would be good to backport. https://github.com/llvm/llvm-project/pull/95463 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Bugfix in getDemandedSrcElements(). (#88623) (PR #95463)
https://github.com/uweigand approved this pull request. https://github.com/llvm/llvm-project/pull/95463 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [lld] release/18.x: [lld] Add target support for SystemZ (s390x) (#75643) (PR #81675)
uweigand wrote: We should also backport this part https://github.com/llvm/llvm-project/pull/81739 to enable building glibc with LLD on s390x. https://github.com/llvm/llvm-project/pull/81675 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [llvm-objcopy] Add SystemZ support (#81841) (PR #82324)
uweigand wrote: > Also, as noted in the original PR, the corresponding doc change needs picking > too. I'll add a cherry-pick for the doc PR if and when this PR is approved. https://github.com/llvm/llvm-project/pull/82324 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [llvm-objcopy] Add SystemZ support (#81841) (PR #82324)
uweigand wrote: > > Also, as noted in the original PR, the corresponding doc change needs > > picking too. > > I'll add a cherry-pick for the doc PR if and when this PR is approved. https://github.com/llvm/llvm-project/pull/82470 https://github.com/llvm/llvm-project/pull/82324 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Use VT (not ArgVT) for SlotVT in LowerCall(). (#82475) (PR #83021)
https://github.com/uweigand approved this pull request. LGTM. This should be backported as a fixes a regression with i128 support. https://github.com/llvm/llvm-project/pull/83021 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Require D12 for i128 accesses in isLegalAddressingMode() (#79221) (PR #83022)
https://github.com/uweigand approved this pull request. LGTM. This should be backported as a fixes a regression with i128 support. https://github.com/llvm/llvm-project/pull/83022 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [lld] [llvm] SystemZ release notes for 18.x. (PR #84560)
uweigand wrote: Thanks @JonPsson1 ! In addition, I see the following user-visible changes: - Support -munaligned-symbols command line option - Support SystemZ target in llvm-objcopy - Support OpenMP library on SystemZ Can you add those as well? https://github.com/llvm/llvm-project/pull/84560 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [lld] [llvm] [openmp] SystemZ release notes for 18.x. (PR #84560)
uweigand wrote: > Looks like #73511 "munaligned-symbols" 34dd8ec never made it into the > 18-release branch... Ah OK, I had missed that. https://github.com/llvm/llvm-project/pull/84560 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [lld] [llvm] [openmp] SystemZ release notes for 18.x. (PR #84560)
https://github.com/uweigand approved this pull request. LGTM, thanks! https://github.com/llvm/llvm-project/pull/84560 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: Fix overflow flag for i128 USUBO (PR #86475)
https://github.com/uweigand requested changes to this pull request. Automatic merge was incorrect. I'll provide a manual merge. https://github.com/llvm/llvm-project/pull/86475 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: Fix overflow flag for i128 USUBO (PR #86475)
https://github.com/uweigand closed https://github.com/llvm/llvm-project/pull/86475 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SystemZ] Fix overflow flag for i128 USUBO (PR #86491)
https://github.com/uweigand created
https://github.com/llvm/llvm-project/pull/86491
We use the VSCBIQ/VSBIQ/VSBCBIQ family of instructions to implement
USUBO/USUBO_CARRY for the i128 data type. However, these instructions use an
inverted sense of the borrow indication flag (a value of 1 indicates *no*
borrow, while a value of 0 indicated borrow). This does not match the
semantics of the boolean "overflow" flag of the USUBO/USUBO_CARRY ISD nodes.
Fix this by generating code to explicitly invert the flag. These cancel out of
the result of USUBO feeds into an USUBO_CARRY.
To avoid unnecessary zero-extend operations, also improve the DAGCombine
handling of ZERO_EXTEND to optimize (zext (xor (trunc))) sequences where
appropriate.
Fixes: https://github.com/llvm/llvm-project/issues/83268
>From 6e89500d88bbce00406d50dd6931872e3e4be9d8 Mon Sep 17 00:00:00 2001
From: Ulrich Weigand
Date: Tue, 19 Mar 2024 11:14:57 +0100
Subject: [PATCH] [SystemZ] Fix overflow flag for i128 USUBO
We use the VSCBIQ/VSBIQ/VSBCBIQ family of instructions to implement
USUBO/USUBO_CARRY for the i128 data type. However, these instructions
use an inverted sense of the borrow indication flag (a value of 1
indicates *no* borrow, while a value of 0 indicated borrow). This
does not match the semantics of the boolean "overflow" flag of the
USUBO/USUBO_CARRY ISD nodes.
Fix this by generating code to explicitly invert the flag. These
cancel out of the result of USUBO feeds into an USUBO_CARRY.
To avoid unnecessary zero-extend operations, also improve the
DAGCombine handling of ZERO_EXTEND to optimize (zext (xor (trunc)))
sequences where appropriate.
Fixes: https://github.com/llvm/llvm-project/issues/83268
---
.../Target/SystemZ/SystemZISelLowering.cpp| 34 +++
llvm/test/CodeGen/SystemZ/int-usub-12.ll | 22
llvm/test/CodeGen/SystemZ/int-usub-13.ll | 2 ++
3 files changed, 58 insertions(+)
diff --git a/llvm/lib/Target/SystemZ/SystemZISelLowering.cpp
b/llvm/lib/Target/SystemZ/SystemZISelLowering.cpp
index 5db04a8bef824a..5e0b0594b0a421 100644
--- a/llvm/lib/Target/SystemZ/SystemZISelLowering.cpp
+++ b/llvm/lib/Target/SystemZ/SystemZISelLowering.cpp
@@ -4252,6 +4252,7 @@ SDValue SystemZTargetLowering::lowerXALUO(SDValue Op,
if (N->getValueType(0) == MVT::i128) {
unsigned BaseOp = 0;
unsigned FlagOp = 0;
+bool IsBorrow = false;
switch (Op.getOpcode()) {
default: llvm_unreachable("Unknown instruction!");
case ISD::UADDO:
@@ -4261,6 +4262,7 @@ SDValue SystemZTargetLowering::lowerXALUO(SDValue Op,
case ISD::USUBO:
BaseOp = ISD::SUB;
FlagOp = SystemZISD::VSCBI;
+ IsBorrow = true;
break;
}
SDValue Result = DAG.getNode(BaseOp, DL, MVT::i128, LHS, RHS);
@@ -4268,6 +4270,9 @@ SDValue SystemZTargetLowering::lowerXALUO(SDValue Op,
Flag = DAG.getNode(ISD::AssertZext, DL, MVT::i128, Flag,
DAG.getValueType(MVT::i1));
Flag = DAG.getZExtOrTrunc(Flag, DL, N->getValueType(1));
+if (IsBorrow)
+ Flag = DAG.getNode(ISD::XOR, DL, Flag.getValueType(),
+ Flag, DAG.getConstant(1, DL, Flag.getValueType()));
return DAG.getNode(ISD::MERGE_VALUES, DL, N->getVTList(), Result, Flag);
}
@@ -4340,6 +4345,7 @@ SDValue
SystemZTargetLowering::lowerUADDSUBO_CARRY(SDValue Op,
if (VT == MVT::i128) {
unsigned BaseOp = 0;
unsigned FlagOp = 0;
+bool IsBorrow = false;
switch (Op.getOpcode()) {
default: llvm_unreachable("Unknown instruction!");
case ISD::UADDO_CARRY:
@@ -4349,14 +4355,21 @@ SDValue
SystemZTargetLowering::lowerUADDSUBO_CARRY(SDValue Op,
case ISD::USUBO_CARRY:
BaseOp = SystemZISD::VSBI;
FlagOp = SystemZISD::VSBCBI;
+ IsBorrow = true;
break;
}
+if (IsBorrow)
+ Carry = DAG.getNode(ISD::XOR, DL, Carry.getValueType(),
+ Carry, DAG.getConstant(1, DL, Carry.getValueType()));
Carry = DAG.getZExtOrTrunc(Carry, DL, MVT::i128);
SDValue Result = DAG.getNode(BaseOp, DL, MVT::i128, LHS, RHS, Carry);
SDValue Flag = DAG.getNode(FlagOp, DL, MVT::i128, LHS, RHS, Carry);
Flag = DAG.getNode(ISD::AssertZext, DL, MVT::i128, Flag,
DAG.getValueType(MVT::i1));
Flag = DAG.getZExtOrTrunc(Flag, DL, N->getValueType(1));
+if (IsBorrow)
+ Flag = DAG.getNode(ISD::XOR, DL, Flag.getValueType(),
+ Flag, DAG.getConstant(1, DL, Flag.getValueType()));
return DAG.getNode(ISD::MERGE_VALUES, DL, N->getVTList(), Result, Flag);
}
@@ -6611,6 +6624,27 @@ SDValue SystemZTargetLowering::combineZERO_EXTEND(
return NewSelect;
}
}
+ // Convert (zext (xor (trunc X), C)) into (xor (trunc X), C') if the size
+ // of the result is smaller than the size of X and all the truncated bits
+ // of X are already zero.
+ if (N0.getOpcode() == ISD::XOR &&
+ N0.hasOneUse() && N0.getOperand(0).hasOneUse() &&
+
[llvm-branch-commits] [llvm] [SystemZ] Fix overflow flag for i128 USUBO (PR #86491)
https://github.com/uweigand milestoned https://github.com/llvm/llvm-project/pull/86491 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Fix overflow flag for i128 USUBO (PR #86491)
https://github.com/uweigand edited https://github.com/llvm/llvm-project/pull/86491 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Fix overflow flag for i128 USUBO (PR #86491)
uweigand wrote: > Hi @uweigand (or anyone else). If you would like to add a note about this fix > in the release notes (completely optional). Please reply to this comment with > a one or two sentence description of the fix. This fix is for a regression that only came in with LLVM 18 due to the rework of i128 support (which is already called out in the LLVM 18 release notes). So I don't think there's really any strong need to add another release note. If we did want to call this out specifically, I'd say something like: - Fix a `llvm.usub.with.overflow.i128` wrong code generation regression that was introduced with LLVM 18.1.0. https://github.com/llvm/llvm-project/pull/86491 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [SystemZ] Handle address clobbering in splitMove(). (#92105) (PR #92221)
https://github.com/uweigand approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/92221 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm-branch] r324726 - [ReleaseNotes] Add SystemZ target section
Author: uweigand Date: Fri Feb 9 02:28:27 2018 New Revision: 324726 URL: http://llvm.org/viewvc/llvm-project?rev=324726&view=rev Log: [ReleaseNotes] Add SystemZ target section Modified: llvm/branches/release_60/docs/ReleaseNotes.rst Modified: llvm/branches/release_60/docs/ReleaseNotes.rst URL: http://llvm.org/viewvc/llvm-project/llvm/branches/release_60/docs/ReleaseNotes.rst?rev=324726&r1=324725&r2=324726&view=diff == --- llvm/branches/release_60/docs/ReleaseNotes.rst (original) +++ llvm/branches/release_60/docs/ReleaseNotes.rst Fri Feb 9 02:28:27 2018 @@ -120,6 +120,15 @@ Changes to the PowerPC Target During this release ... +Changes to the SystemZ Target +- + +During this release the SystemZ target has: + +* Added support for 128-bit atomic operations. + +* Added support for the "o" constraint for inline asm statements. + Changes to the X86 Target - ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] b3a5abc - [NFC][Doc] Mention SystemZ supports StackMap generation
Author: Ulrich Weigand Date: 2021-01-21T18:29:46+01:00 New Revision: b3a5abcb36967bd4a83c0c12259d5193ac1a8245 URL: https://github.com/llvm/llvm-project/commit/b3a5abcb36967bd4a83c0c12259d5193ac1a8245 DIFF: https://github.com/llvm/llvm-project/commit/b3a5abcb36967bd4a83c0c12259d5193ac1a8245.diff LOG: [NFC][Doc] Mention SystemZ supports StackMap generation Support available as of commit 5eb64110d241cf2506f54ade3c2693beed42dd8f. Differential Revision: https://reviews.llvm.org/D95040 Added: Modified: llvm/docs/StackMaps.rst Removed: diff --git a/llvm/docs/StackMaps.rst b/llvm/docs/StackMaps.rst index 2ceb408097a7..7c9cead3647d 100644 --- a/llvm/docs/StackMaps.rst +++ b/llvm/docs/StackMaps.rst @@ -514,4 +514,4 @@ Supported Architectures Support for StackMap generation and the related intrinsics requires some code for each backend. Today, only a subset of LLVM's backends are supported. The currently supported architectures are X86_64, -PowerPC, and Aarch64. +PowerPC, Aarch64 and SystemZ. ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] ebef921 - [SystemZ] Remove most hard-coded R1D instances for sibcalls
Author: Ulrich Weigand
Date: 2020-12-15T16:31:18+01:00
New Revision: ebef92169ca5a50fb8aeec08f35ccb919311acc1
URL:
https://github.com/llvm/llvm-project/commit/ebef92169ca5a50fb8aeec08f35ccb919311acc1
DIFF:
https://github.com/llvm/llvm-project/commit/ebef92169ca5a50fb8aeec08f35ccb919311acc1.diff
LOG: [SystemZ] Remove most hard-coded R1D instances for sibcalls
Indirect sibling calls need to use %r1 to hold the target address.
This is currently hard-coded in many places. This is not only
unnecessary, but makes future changes in this area difficult.
This patch now encodes the target address as operand without
hard coding a register in most places throughout the MI back-end.
Code generation still always uses %r1, but this is now decided
solely in one place in SystemZTargetLowering::LowerCall.
NFC intended.
Added:
Modified:
llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
llvm/lib/Target/SystemZ/SystemZElimCompare.cpp
llvm/lib/Target/SystemZ/SystemZInstrInfo.cpp
llvm/lib/Target/SystemZ/SystemZInstrInfo.td
Removed:
diff --git a/llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
b/llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
index 4109bfc11337..584737e1d940 100644
--- a/llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
+++ b/llvm/lib/Target/SystemZ/SystemZAsmPrinter.cpp
@@ -236,14 +236,15 @@ void SystemZAsmPrinter::emitInstruction(const
MachineInstr *MI) {
break;
case SystemZ::CallBR:
-LoweredMI = MCInstBuilder(SystemZ::BR).addReg(SystemZ::R1D);
+LoweredMI = MCInstBuilder(SystemZ::BR)
+ .addReg(MI->getOperand(0).getReg());
break;
case SystemZ::CallBCR:
LoweredMI = MCInstBuilder(SystemZ::BCR)
.addImm(MI->getOperand(0).getImm())
.addImm(MI->getOperand(1).getImm())
- .addReg(SystemZ::R1D);
+ .addReg(MI->getOperand(2).getReg());
break;
case SystemZ::CRBCall:
@@ -251,7 +252,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addReg(MI->getOperand(1).getReg())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -260,7 +261,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addReg(MI->getOperand(1).getReg())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -269,7 +270,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addImm(MI->getOperand(1).getImm())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -278,7 +279,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addImm(MI->getOperand(1).getImm())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -287,7 +288,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addReg(MI->getOperand(1).getReg())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -296,7 +297,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addReg(MI->getOperand(1).getReg())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -305,7 +306,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addImm(MI->getOperand(1).getImm())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
@@ -314,7 +315,7 @@ void SystemZAsmPrinter::emitInstruction(const MachineInstr
*MI) {
.addReg(MI->getOperand(0).getReg())
.addImm(MI->getOperand(1).getImm())
.addImm(MI->getOperand(2).getImm())
- .addReg(SystemZ::R1D)
+ .addReg(MI->getOperand(3).getReg())
.addImm(0);
break;
diff --git a/llvm/lib/Target/SystemZ/SystemZElimCompare.cpp
b/llvm/lib/Target/SystemZ/SystemZElimCompare.cpp
index 2f0cf0317029..19b703bbb226 100644
--- a/llvm/lib/Target/SystemZ/SystemZElimCompare.cpp
+++ b/llvm/lib/Target/SystemZ/SystemZElimCompare.cpp
@@ -640,18 +640,22 @@ bool SystemZElimCompare::fuseCompareOperations(
MachineOperand CCMask(MBBI->getOperand(1));
assert((CCMask.getImm() & ~SystemZ::CCMASK_ICMP) == 0 &&
"Invalid condition-co
[llvm-branch-commits] [llvm] dda0a18 - [LLVM 11] Add SystemZ changes to release notes
Author: Ulrich Weigand Date: 2020-09-29T14:59:38+02:00 New Revision: dda0a1867cc0c4ace4535f179aec85c3ff8cfa96 URL: https://github.com/llvm/llvm-project/commit/dda0a1867cc0c4ace4535f179aec85c3ff8cfa96 DIFF: https://github.com/llvm/llvm-project/commit/dda0a1867cc0c4ace4535f179aec85c3ff8cfa96.diff LOG: [LLVM 11] Add SystemZ changes to release notes Differential Revision: https://reviews.llvm.org/D88479 Added: Modified: llvm/docs/ReleaseNotes.rst Removed: diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst index d724ba09502a..db64fa281018 100644 --- a/llvm/docs/ReleaseNotes.rst +++ b/llvm/docs/ReleaseNotes.rst @@ -241,6 +241,21 @@ Bug fixes: * The correct libcall is now emitted for converting a float/double to a 32-bit signed or unsigned integer on RV64 targets lacking the F or D extensions. +Changes to the SystemZ Target +- + +* Added support for the MemorySanitizer and the LeakSanitizer. +* Added support for the ``-fstack-clash-protection`` command line option. +* Enhanced the assembler parser to allow using `%r0` even in an address + register context, and to allow specifying registers using plain integer + numbers instead of register names everywhere. +* Fixed wrong code generation violating the platform ABI when passing + a C++ class (not struct) type having only a single member of + floating-point type. +* Fixed wrong code generation when using the `vec_store_len_r` or + `vec_load_len_r` intrinsics with an immediate length argument of + 16 or larger. +* Miscellaneous codegen enhancements, in particular to improve vector code. Changes to the X86 Target - ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm-branch] r339355 - [7.0 branch] Update release notes (SystemZ, TableGen)
Author: uweigand Date: Thu Aug 9 09:18:00 2018 New Revision: 339355 URL: http://llvm.org/viewvc/llvm-project?rev=339355&view=rev Log: [7.0 branch] Update release notes (SystemZ, TableGen) This updates the 7.0 branch release notes to mention the SystemZ specific changes, and also the new support for multi-alternative patterns in TableGen (see D48545). Reviewed by: hans Differential Revision: https://reviews.llvm.org/D50514 Modified: llvm/branches/release_70/docs/ReleaseNotes.rst Modified: llvm/branches/release_70/docs/ReleaseNotes.rst URL: http://llvm.org/viewvc/llvm-project/llvm/branches/release_70/docs/ReleaseNotes.rst?rev=339355&r1=339354&r2=339355&view=diff == --- llvm/branches/release_70/docs/ReleaseNotes.rst (original) +++ llvm/branches/release_70/docs/ReleaseNotes.rst Thu Aug 9 09:18:00 2018 @@ -161,6 +161,26 @@ Changes to the PowerPC Target During this release ... +Changes to the SystemZ Target +- + +During this release the SystemZ target has: + +* Added support for vector registers in inline asm statements. + +* Added support for stackmaps, patchpoints, and the anyregcc + calling convention. + +* Changed the default function alignment to 16 bytes. + +* Improved codegen for condition code handling. + +* Improved instruction scheduling and microarchitecture tuning for z13/z14. + +* Fixed support for generating GCOV coverage data. + +* Fixed some codegen bugs. + Changes to the X86 Target - @@ -198,6 +218,10 @@ Changes to the DAG infrastructure * The SETCCE opcode has now been removed in favor of SETCCCARRY. +* TableGen now supports multi-alternative pattern fragments via the PatFrags + class. PatFrag is now derived from PatFrags, which may require minor + changes to backends that directly access PatFrag members. + External Open Source Projects Using LLVM 7 == ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt-branch] r366690 - Revert r366413 on LLVM 9 branch
Author: uweigand
Date: Mon Jul 22 07:07:55 2019
New Revision: 366690
URL: http://llvm.org/viewvc/llvm-project?rev=366690&view=rev
Log:
Revert r366413 on LLVM 9 branch
This commit caused test suite failures on multiple platforms and
has been reverted on mainline as r366472/r366482.
Removed:
compiler-rt/branches/release_90/test/asan/TestCases/Linux/dlopen-mixed-c-cxx.c
Modified:
compiler-rt/branches/release_90/lib/interception/interception_linux.cc
Modified: compiler-rt/branches/release_90/lib/interception/interception_linux.cc
URL:
http://llvm.org/viewvc/llvm-project/compiler-rt/branches/release_90/lib/interception/interception_linux.cc?rev=366690&r1=366689&r2=366690&view=diff
==
--- compiler-rt/branches/release_90/lib/interception/interception_linux.cc
(original)
+++ compiler-rt/branches/release_90/lib/interception/interception_linux.cc Mon
Jul 22 07:07:55 2019
@@ -33,7 +33,7 @@ static int StrCmp(const char *s1, const
}
#endif
-static void *GetFuncAddr(const char *name, uptr wrapper_addr) {
+static void *GetFuncAddr(const char *name) {
#if SANITIZER_NETBSD
// FIXME: Find a better way to handle renames
if (StrCmp(name, "sigaction"))
@@ -47,18 +47,13 @@ static void *GetFuncAddr(const char *nam
// want the address of the real definition, though, so look it up using
// RTLD_DEFAULT.
addr = dlsym(RTLD_DEFAULT, name);
-
-// In case `name' is not loaded, dlsym ends up finding the actual wrapper.
-// We don't want to intercept the wrapper and have it point to itself.
-if ((uptr)addr == wrapper_addr)
- addr = nullptr;
}
return addr;
}
bool InterceptFunction(const char *name, uptr *ptr_to_real, uptr func,
uptr wrapper) {
- void *addr = GetFuncAddr(name, wrapper);
+ void *addr = GetFuncAddr(name);
*ptr_to_real = (uptr)addr;
return addr && (func == wrapper);
}
Removed:
compiler-rt/branches/release_90/test/asan/TestCases/Linux/dlopen-mixed-c-cxx.c
URL:
http://llvm.org/viewvc/llvm-project/compiler-rt/branches/release_90/test/asan/TestCases/Linux/dlopen-mixed-c-cxx.c?rev=366689&view=auto
==
---
compiler-rt/branches/release_90/test/asan/TestCases/Linux/dlopen-mixed-c-cxx.c
(original)
+++
compiler-rt/branches/release_90/test/asan/TestCases/Linux/dlopen-mixed-c-cxx.c
(removed)
@@ -1,42 +0,0 @@
-// RUN: %clangxx_asan -xc++ -shared -fPIC -o %t.so - < %s
-// RUN: %clang_asan %s -o %t.out -ldl
-// RUN: ASAN_OPTIONS=verbosity=1 not %t.out %t.so 2>&1 | FileCheck %s
-//
-// CHECK: AddressSanitizer: failed to intercept '__cxa_throw'
-//
-// dlopen() can not be intercepted on Android
-// UNSUPPORTED: android
-#ifdef __cplusplus
-
-static void foo(void) {
- int i = 0;
- throw(i);
-}
-
-extern "C" {
-int bar(void);
-};
-int bar(void) {
- try {
-foo();
- } catch (int i) {
-return i;
- }
- return -1;
-}
-
-#else
-
-#include
-#include
-
-int main(int argc, char **argv) {
- int (*bar)(void);
- void *handle = dlopen(argv[1], RTLD_LAZY);
- assert(handle);
- bar = dlsym(handle, "bar");
- assert(bar);
- return bar();
-}
-
-#endif
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm-branch] r366693 - [SystemZ] Add release notes on the LLVM 9 branch
Author: uweigand Date: Mon Jul 22 07:39:02 2019 New Revision: 366693 URL: http://llvm.org/viewvc/llvm-project?rev=366693&view=rev Log: [SystemZ] Add release notes on the LLVM 9 branch Modified: llvm/branches/release_90/docs/ReleaseNotes.rst Modified: llvm/branches/release_90/docs/ReleaseNotes.rst URL: http://llvm.org/viewvc/llvm-project/llvm/branches/release_90/docs/ReleaseNotes.rst?rev=366693&r1=366692&r2=366693&view=diff == --- llvm/branches/release_90/docs/ReleaseNotes.rst (original) +++ llvm/branches/release_90/docs/ReleaseNotes.rst Mon Jul 22 07:39:02 2019 @@ -103,6 +103,27 @@ Changes to the PowerPC Target During this release ... +Changes to the SystemZ Target +- + +* Support for the arch13 architecture has been added. When using the + ``-march=arch13`` option, the compiler will generate code making use of + new instructions introduced with the vector enhancement facility 2 + and the miscellaneous instruction extension facility 2. + The ``-mtune=arch13`` option enables arch13 specific instruction + scheduling and tuning without making use of new instructions. + +* Builtins for the new vector instructions have been added and can be + enabled using the ``-mzvector`` option. Support for these builtins + is indicated by the compiler predefining the ``__VEC__`` macro to + the value ``10303``. + +* The compiler now supports and automatically generates alignment hints + on vector load and store instructions. + +* Various code-gen improvements, in particular related to improved + instruction selection and register allocation. + Changes to the X86 Target - ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] aeba7ba - Add SystemZ release notes
Author: Ulrich Weigand Date: 2020-02-11T12:52:45+01:00 New Revision: aeba7ba9f3dada09e196d174e7f13b82f01300db URL: https://github.com/llvm/llvm-project/commit/aeba7ba9f3dada09e196d174e7f13b82f01300db DIFF: https://github.com/llvm/llvm-project/commit/aeba7ba9f3dada09e196d174e7f13b82f01300db.diff LOG: Add SystemZ release notes Added: Modified: llvm/docs/ReleaseNotes.rst Removed: diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst index 49fabc56c054..20e49b20f95d 100644 --- a/llvm/docs/ReleaseNotes.rst +++ b/llvm/docs/ReleaseNotes.rst @@ -168,6 +168,19 @@ Tools: * llvm-objdump supports disassembling physical sections for XCOFF object files +Changes to the SystemZ Target +- + +* Added support for the ``-march=z15`` and ``-mtune=z15`` command line options + (as aliases to the existing ``-march=arch13`` and ``-mtune=arch13`` options). +* Added support for the ``-march=native`` command line option. +* Added support for the ``-mfentry``, ``-mnop-mcount``, and ``-mrecord-mcount`` + command line options. +* Added support for the GHC calling convention. +* Miscellaneous codegen enhancements, in particular to enable better + reuse of condition code values and improved use of conditional + move instructions. + Changes to the X86 Target - ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [SystemZ] Fix codegen for _[u]128 intrinsics (PR #111376)
https://github.com/uweigand approved this pull request. I think this should be a candidate for backport, as the problem is a miscompilation regression and the fix is straightforward. https://github.com/llvm/llvm-project/pull/111376 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/19.x: [SystemZ] Fix codegen for _[u]128 intrinsics (PR #111376)
uweigand wrote: > @uweigand (or anyone else). If you would like to add a note about this fix in > the release notes (completely optional). Please reply to this comment with a > one or two sentence description of the fix. When you are done, please add the > release:note label to this PR. Fix a regression introduced with the LLVM 18 release, which caused incorrect code to be generated by the following SystemZ vector intrinsics: vec_add_u128, vec_addc_u128, vec_adde_u128, vec_addec_u128, vec_sub_u128, vec_subc_u128, vec_sube_u128, vec_subec_u128, vec_sum_u128, vec_msum_u128, vec_gfmsum_128, vec_gfmsum_accum_128. https://github.com/llvm/llvm-project/pull/111376 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/19.x: [SystemZ] Use the EVT version of getVectorVT() in combineTruncateExtract(). (#100150) (PR #116510)
https://github.com/uweigand approved this pull request. LGTM, thanks! https://github.com/llvm/llvm-project/pull/116510 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/20.x: [SystemZ] Replace SELRMux with COPY in case of identical operands. (#125108) (PR #125236)
https://github.com/uweigand approved this pull request. Sorry for the delay, I've been travelling. This looks good to backport to me. Thanks! https://github.com/llvm/llvm-project/pull/125236 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -2767,15 +2774,55 @@ MCSection
*TargetLoweringObjectFileGOFF::getExplicitSectionGlobal(
MCSection *TargetLoweringObjectFileGOFF::getSectionForLSDA(
const Function &F, const MCSymbol &FnSym, const TargetMachine &TM) const {
std::string Name = ".gcc_exception_table." + F.getName().str();
- return getContext().getGOFFSection(Name, SectionKind::getData(), nullptr, 0);
+ constexpr bool Is64Bit = true;
+ constexpr bool UsesXPLINK = true;
+ return getContext().getGOFFSection(
+ SectionKind::getData(), GOFF::WSA,
+ GOFF::EDAttr{false, GOFF::ESD_EXE_DATA, GOFF::AMODE,
+ GOFF::RMODE, GOFF::ESD_NS_Parts,
+ GOFF::ESD_TS_ByteOriented, GOFF::ESD_BA_Merge,
+ GOFF::LOADBEHAVIOR, GOFF::ESD_RQ_0,
+ GOFF::ESD_ALIGN_Doubleword},
+ Name,
+ GOFF::PRAttr{true, false, GOFF::ESD_EXE_Unspecified, GOFF::ESD_NS_Parts,
+ GOFF::LINKAGE, GOFF::AMODE,
+ GOFF::ESD_BSC_Section, GOFF::ESD_DSS_NoWarning,
+ GOFF::ESD_ALIGN_Fullword, 0});
}
MCSection *TargetLoweringObjectFileGOFF::SelectSectionForGlobal(
const GlobalObject *GO, SectionKind Kind, const TargetMachine &TM) const {
auto *Symbol = TM.getSymbol(GO);
- if (Kind.isBSS())
-return getContext().getGOFFSection(Symbol->getName(),
SectionKind::getBSS(),
- nullptr, 0);
-
- return getContext().getObjectFileInfo()->getTextSection();
+ constexpr bool Is64Bit = true;
+ constexpr bool UsesXPLINK = true;
+
+ if (Kind.isBSS() || Kind.isData()) {
uweigand wrote:
This also adds `isData` - was that deliberate?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -16,34 +16,95 @@
#define LLVM_MC_MCSECTIONGOFF_H
#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
#include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
namespace llvm {
class MCExpr;
class MCSectionGOFF final : public MCSection {
-private:
- MCSection *Parent;
- uint32_t Subsection;
+ // Parent of this section. Implies that the parent is emitted first.
+ MCSectionGOFF *Parent;
+
+ // The attributes of the GOFF symbols.
+ GOFF::SDAttr SDAttributes;
+ GOFF::EDAttr EDAttributes;
+ GOFF::PRAttr PRAttributes;
uweigand wrote:
union might be better?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -230,10 +230,11 @@ class MCObjectFileInfo {
MCSection *GLJMPSection = nullptr;
// GOFF specific sections.
- MCSection *PPA1Section = nullptr;
- MCSection *PPA2Section = nullptr;
- MCSection *PPA2ListSection = nullptr;
- MCSection *ADASection = nullptr;
+ MCSection *RootSDSection = nullptr;
+ MCSection *PPA2ListEDSection = nullptr;
+ MCSection *PPA2ListPRSection = nullptr;
+ MCSection *ADAEDSection = nullptr;
+ MCSection *ADAPRSection = nullptr;
uweigand wrote:
I don't think we really need two pointers each here. Just the main section
(i.e. the one where code is emitted to) should be enough, shouldn't it?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -16,6 +16,9 @@ namespace llvm {
class GOFFObjectWriter;
class MCGOFFStreamer : public MCObjectStreamer {
+ std::string RootSDName;
+ std::string ADAPRName;
uweigand wrote:
These are no longer used, I think.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_RMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_RMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_RMODE_None:
+ break;
+}
+if (UseParenthesis)
+ OS << ')';
+ }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+ bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+ GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+ GOFF::ESDLoadingBehavior LoadBehavior,
+ GOFF::ESDExecutable Executable, bool IsReadOnly,
+ StringRef PartName) {
+ if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_AMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_AMODE_ANY:
+ OS << "ANY";
+ break;
+case GOFF::ESD_AMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_AMODE_MIN:
+ OS << "ANY64";
+ break;
+case GOFF::ESD_AMODE_None:
+ break;
+}
+OS << "\n";
+ }
+ if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+ }
+ OS << Name << " CATTR ";
+ OS << "ALIGN(" << static_cast(Alignment) << ")";
+ switch (LoadBehavior) {
+ case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+ case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+ default:
+break;
+ }
+ switch (Executable) {
+ case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+ case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+ default:
+break;
+ }
+ if (IsReadOnly)
+OS << ",READONLY";
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+ }
+ if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+ OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+ switch (SymbolType) {
+ case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+ }
+ case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+ Emitted = true;
+} else
+ OS << Name << " CATTR ,\n";
+break;
+ }
+ case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
+PRAttributes.Executable, PRAttributes.IsReadOnly, Name);
+ ED->Emitted = true;
+ Emitted = true;
+} else
+ OS << ED->getName() << " CATTR ,\n";
uweigand wrote:
Why the comma at the end?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_RMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_RMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_RMODE_None:
+ break;
+}
+if (UseParenthesis)
+ OS << ')';
+ }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+ bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+ GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+ GOFF::ESDLoadingBehavior LoadBehavior,
+ GOFF::ESDExecutable Executable, bool IsReadOnly,
+ StringRef PartName) {
+ if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_AMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_AMODE_ANY:
+ OS << "ANY";
+ break;
+case GOFF::ESD_AMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_AMODE_MIN:
+ OS << "ANY64";
+ break;
+case GOFF::ESD_AMODE_None:
+ break;
+}
+OS << "\n";
+ }
+ if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+ }
+ OS << Name << " CATTR ";
+ OS << "ALIGN(" << static_cast(Alignment) << ")";
+ switch (LoadBehavior) {
+ case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+ case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+ default:
+break;
+ }
+ switch (Executable) {
+ case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+ case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+ default:
+break;
+ }
+ if (IsReadOnly)
+OS << ",READONLY";
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+ }
+ if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+ OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+ switch (SymbolType) {
+ case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+ }
+ case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+ Emitted = true;
+} else
+ OS << Name << " CATTR ,\n";
+break;
+ }
+ case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
+PRAttributes.Executable, PRAttributes.IsReadOnly, Name);
uweigand wrote:
Do we also need to set CATTR PRIORITY ?
There are some other PR properties that seem to require XATTR to be set via
HLASM, in particular XATTR SCOPE, LINKAGE, and potentially
REFERENCE(CODE/DATA). (I'm not sure how the latter interacts with CATTR
[NON]EXECUTABLE, however ... Also, the GOFF docs seem to imply that there is no
executable property on PRs, but that may just be wrong ...)
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
uweigand wrote:
For LD (as opposed to ER), it seems "strong" is the only allowed value here.
Again, if this is true, it doesn't make much sense to specify it.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
uweigand wrote:
According to the GOFF docs, while the executable flag is supported on ED, it's
only purpose is to act as default for the executable flags in all LDs defined
in this ED. Assuming we set the flag in the LDs, do we also need it in the ED?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+ bool IsRenamable = false;
+ bool IsReadOnly = false; // Not documented.
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+ GOFF::ESDDuplicateSymbolSeverity DuplicateSymbolSeverity =
+ GOFF::ESD_DSS_NoWarning;
uweigand wrote:
How would you set this via HLASM? I wasn't able to find anything in the docs
...
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_RMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_RMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_RMODE_None:
+ break;
+}
+if (UseParenthesis)
+ OS << ')';
+ }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+ bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+ GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+ GOFF::ESDLoadingBehavior LoadBehavior,
+ GOFF::ESDExecutable Executable, bool IsReadOnly,
+ StringRef PartName) {
+ if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
uweigand wrote:
As above, reading the HLASM docs, the "AMODE" command in GOFF mode should refer
to a *symbol* name, not a section name. This may be a bit confusing due the
section start symbol with the same name as the section - I think we should
actually emit the AMODE for *that* instead.
(There is some HLASM backward compat mode for AMODE on a section name, but that
also actually uses some implicitly generated section start symbol instead.)
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+ bool IsRenamable = false;
+ bool IsReadOnly = false; // Not documented.
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
uweigand wrote:
See above for the NameSpace comment.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+ bool IsRenamable = false;
+ bool IsReadOnly = false; // Not documented.
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
uweigand wrote:
See above for the Amode comment.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
uweigand wrote:
According to the GOFF docs, the NameSpace of LD or PR records must always match
the NameSpace of the parent ED record. If that's true, I don't think it is
worthwhile allowing to specify this separately here.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_RMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_RMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_RMODE_None:
+ break;
+}
+if (UseParenthesis)
+ OS << ')';
+ }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+ bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+ GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+ GOFF::ESDLoadingBehavior LoadBehavior,
+ GOFF::ESDExecutable Executable, bool IsReadOnly,
+ StringRef PartName) {
+ if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_AMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_AMODE_ANY:
+ OS << "ANY";
+ break;
+case GOFF::ESD_AMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_AMODE_MIN:
+ OS << "ANY64";
+ break;
+case GOFF::ESD_AMODE_None:
+ break;
+}
+OS << "\n";
+ }
+ if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+ }
+ OS << Name << " CATTR ";
+ OS << "ALIGN(" << static_cast(Alignment) << ")";
+ switch (LoadBehavior) {
+ case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+ case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+ default:
+break;
+ }
+ switch (Executable) {
+ case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+ case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+ default:
+break;
+ }
+ if (IsReadOnly)
+OS << ",READONLY";
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+ }
+ if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+ OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+ switch (SymbolType) {
+ case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+ }
+ case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+ Emitted = true;
+} else
+ OS << Name << " CATTR ,\n";
+break;
+ }
+ case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
uweigand wrote:
LoadBehavior and Rmode are only supported on ED, not PR. Should we even emit
those with the CATTR PART at all, or only with the base CATTR for the ED?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
uweigand wrote:
The whole Amode/Rmode handling is a bit confusing to me. As I understand the
GOFF docs, Amode is supposed to be a *symbol* property (i.e. set on LD and ER
records) while Rmode is supposed to be an *element* property (i.e. set on ED
records). So it is unclear what an Amode property on ED or PR is supposed to
do, exactly. There also doesn't seem to be a way to specify those with any
HLASM command I can see.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_RMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_RMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_RMODE_None:
+ break;
+}
+if (UseParenthesis)
+ OS << ')';
+ }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+ bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+ GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+ GOFF::ESDLoadingBehavior LoadBehavior,
+ GOFF::ESDExecutable Executable, bool IsReadOnly,
+ StringRef PartName) {
+ if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_AMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_AMODE_ANY:
+ OS << "ANY";
+ break;
+case GOFF::ESD_AMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_AMODE_MIN:
+ OS << "ANY64";
+ break;
+case GOFF::ESD_AMODE_None:
+ break;
+}
+OS << "\n";
+ }
+ if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
uweigand wrote:
The plain RMODE in GOFF mode HLASM also seems to be only for backward-compat
purposes and sets the mode on an implicitly generated B_TEXT class. I don't
think we ever use that class at all - do we really want to set this? We do
need the "CATTR RMODE" which sets the mode on our actual class.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -239,6 +298,63 @@ class GOFFWriter {
GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
: OS(OS), Asm(Asm) {}
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+ if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+ Section.getSDAttributes());
+writeSymbol(SD);
+ }
+
+ if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+ ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+ }
+
+ if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {
uweigand wrote:
OK, thanks for following up on this.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -16,34 +16,94 @@
#define LLVM_MC_MCSECTIONGOFF_H
#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/MC/MCGOFFAttributes.h"
#include "llvm/MC/MCSection.h"
+#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/raw_ostream.h"
namespace llvm {
class MCExpr;
class MCSectionGOFF final : public MCSection {
-private:
- MCSection *Parent;
- uint32_t Subsection;
+ // Parent of this section. Implies that the parent is emitted first.
+ MCSectionGOFF *Parent;
+
+ // The attributes of the GOFF symbols.
+ GOFF::SDAttr SDAttributes;
+ GOFF::EDAttr EDAttributes;
+ GOFF::PRAttr PRAttributes;
+
+ // The type of this section.
+ GOFF::ESDSymbolType SymbolType;
+
+ // Indicates that the PR symbol needs to set the length of the section to a
+ // non-zero value. This is only a problem with the ADA PR - the binder will
+ // generate an error in this case.
+ unsigned RequiresNonZeroLength : 1;
friend class MCContext;
- MCSectionGOFF(StringRef Name, SectionKind K, MCSection *P, uint32_t Sub)
+ MCSectionGOFF(StringRef Name, SectionKind K, GOFF::ESDSymbolType SymbolType,
+GOFF::SDAttr SDAttributes, GOFF::EDAttr EDAttributes,
+GOFF::PRAttr PRAttributes, MCSectionGOFF *Parent = nullptr)
: MCSection(SV_GOFF, Name, K.isText(), /*IsVirtual=*/false, nullptr),
-Parent(P), Subsection(Sub) {}
+Parent(Parent), SDAttributes(SDAttributes), EDAttributes(EDAttributes),
+PRAttributes(PRAttributes), SymbolType(SymbolType) {}
public:
void printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
raw_ostream &OS,
-uint32_t /*Subsection*/) const override {
-OS << "\t.section\t\"" << getName() << "\"\n";
+uint32_t Subsection) const override {
+switch (SymbolType) {
+case GOFF::ESD_ST_SectionDefinition:
+ OS << Name << " CSECT\n";
+ break;
+case GOFF::ESD_ST_ElementDefinition:
+ getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+ OS << Name << " CATTR\n";
+ break;
+case GOFF::ESD_ST_PartReference:
+ getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+ OS << Name << " XATTR\n";
uweigand wrote:
This looks wrong. For a PR, you should print a CATTR (with the ED class name)
using a PART attribute holding the PR name. XATTR should be used when
printing a symbol, e.g. to hold the PSECT attibute for the ADA section. (Also,
for full generality, you should probably emit the remaining section and symbol
attributes with the CATTR and XATTR where applicable.)
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [llvm] [release/20.x] Support z17 processor name and scheduler description (PR #135413)
https://github.com/uweigand edited https://github.com/llvm/llvm-project/pull/135413 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [llvm] [release/20.x] Support z17 processor name and scheduler description (PR #135413)
https://github.com/uweigand milestoned https://github.com/llvm/llvm-project/pull/135413 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -671,24 +672,48 @@ MCContext::getELFUniqueIDForEntsize(StringRef
SectionName, unsigned Flags,
: std::nullopt;
}
-MCSectionGOFF *MCContext::getGOFFSection(StringRef Section, SectionKind Kind,
- MCSection *Parent,
- uint32_t Subsection) {
+MCSectionGOFF *
+MCContext::getGOFFSection(SectionKind Kind, GOFF::ESDSymbolType SymbolType,
+ StringRef Name, GOFF::SDAttr SDAttributes,
+ GOFF::EDAttr EDAttributes, GOFF::PRAttr PRAttributes,
+ MCSection *Parent) {
+ GOFFSectionKey T{Name, SymbolType};
// Do the lookup. If we don't have a hit, return a new section.
- auto IterBool =
- GOFFUniquingMap.insert(std::make_pair(Section.str(), nullptr));
+ auto IterBool = GOFFUniquingMap.insert(std::make_pair(T, nullptr));
uweigand wrote:
The way the key is defined means that we there can only be a single instance of
a section with the same name and type. For example, there can only be a single
ED with name C_WSA64. This doesn't look correct to me.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -239,6 +298,63 @@ class GOFFWriter {
GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
: OS(OS), Asm(Asm) {}
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+ if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+ Section.getSDAttributes());
+writeSymbol(SD);
+ }
+
+ if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
uweigand wrote:
Do we really need a special flag for this? As I understand it, the length
should remain zero for EDs that have PRs inside, i.e. those that use
GOFF::ESD_BA_Merge - can't we just check for that? Also, in those cases no
text should ever get emitted into the ED section, so it's size should be zero
naturally?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -599,8 +615,23 @@ class MCContext {
unsigned Flags,
unsigned EntrySize);
- MCSectionGOFF *getGOFFSection(StringRef Section, SectionKind Kind,
-MCSection *Parent, uint32_t Subsection = 0);
+private:
+ MCSectionGOFF *getGOFFSection(SectionKind Kind,
+GOFF::ESDSymbolType SymbolType, StringRef Name,
+GOFF::SDAttr SDAttributes,
+GOFF::EDAttr EDAttributes,
+GOFF::PRAttr PRAttributes, MCSection *Parent);
+
+public:
+ MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::SDAttr SDAttributes,
+MCSection *Parent = nullptr);
uweigand wrote:
SD can never have a parent, so this should be removed.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -26,6 +27,29 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
return static_cast(getAssembler().getWriter());
}
+void MCGOFFStreamer::initSections(bool /*NoExecStack*/,
+ const MCSubtargetInfo &STI) {
+ MCContext &Ctx = getContext();
+ // Emit the text section.
+ switchSection(Ctx.getObjectFileInfo()->getTextSection());
+}
+
+namespace {
+// Make sure that all section are registered in the correct order.
+void registerSectionHierarchy(MCAssembler &Asm, MCSectionGOFF *Section) {
+ if (Section->isRegistered())
+return;
+ if (Section->getParent())
+registerSectionHierarchy(Asm, Section->getParent());
+ registerSectionHierarchy(Asm, Section);
uweigand wrote:
Huh? How is this not just an endless recursion?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -26,6 +27,29 @@ GOFFObjectWriter &MCGOFFStreamer::getWriter() {
return static_cast(getAssembler().getWriter());
}
+void MCGOFFStreamer::initSections(bool /*NoExecStack*/,
+ const MCSubtargetInfo &STI) {
+ MCContext &Ctx = getContext();
+ // Emit the text section.
+ switchSection(Ctx.getObjectFileInfo()->getTextSection());
+}
uweigand wrote:
How is this different from the default implementation of `initSections`?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -239,6 +298,63 @@ class GOFFWriter {
GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
: OS(OS), Asm(Asm) {}
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+ if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+ Section.getSDAttributes());
+writeSymbol(SD);
+ }
+
+ if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+ ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+ }
+
+ if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {
uweigand wrote:
I see. I think we should implement this rule then - if a section is the target
of an ADA link, it cannot be empty. That would be preferable to upper layers
having to remember setting this flag. (I guess we could still have a flag
internally, but that would get automatically set e.g. by `setADA`.)
Or, in the alternative, should we simply *not* set the ADA link if the target
section is empty? If an ADA section, it cannot actually be used for anything,
so do we even need to register it as ADA for a text section?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
uweigand wrote: > I use the ordinal number +1 of the section as the section number, but still > need a counter for the symbols. Can't we just set the ordinal to the correct value to begin with? ELF sets the ordinals while writing out the sections; I think we might as well do the same. (The point being that if we have already ensured we write sections in the correct order, then we will only ever need to refer to ordinals of sections that have already been written.) Then we'd be back to a single counter used by the writer for all GOFF symbol records, those that come from sections as well as those that come from symbols. https://github.com/llvm/llvm-project/pull/133799 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
@@ -688,28 +689,32 @@ MCSectionGOFF *MCContext::getGOFFSection(SectionKind
Kind, StringRef Name,
return Iter->second;
StringRef CachedName = StringRef(Iter->first.c_str(), Name.size());
- MCSectionGOFF *GOFFSection = new (GOFFAllocator.Allocate()) MCSectionGOFF(
- CachedName, Kind, Attributes, static_cast(Parent));
+ MCSectionGOFF *GOFFSection = new (GOFFAllocator.Allocate())
+ MCSectionGOFF(CachedName, Kind, IsVirtual, Attributes,
+static_cast(Parent));
Iter->second = GOFFSection;
allocInitialFragment(*GOFFSection);
return GOFFSection;
}
MCSectionGOFF *MCContext::getGOFFSection(SectionKind Kind, StringRef Name,
GOFF::SDAttr SDAttributes) {
- return getGOFFSection(Kind, Name, SDAttributes, nullptr);
+ return getGOFFSection(Kind, Name, SDAttributes, nullptr,
+ /*IsVirtual=*/true);
}
MCSectionGOFF *MCContext::getGOFFSection(SectionKind Kind, StringRef Name,
GOFF::EDAttr EDAttributes,
- MCSection *Parent) {
- return getGOFFSection(Kind, Name, EDAttributes, Parent);
+ MCSection *Parent, bool IsVirtual) {
+ return getGOFFSection(Kind, Name, EDAttributes, Parent,
+ IsVirtual);
uweigand wrote:
Can we deduce the `IsVirtual` property from `EDAttributes.BindAlgorithm ==
GOFF::ESD_BA_Merge` here? Having to explicitly specific it with every caller
seems error-prone.
https://github.com/llvm/llvm-project/pull/137235
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -230,10 +230,11 @@ class MCObjectFileInfo {
MCSection *GLJMPSection = nullptr;
// GOFF specific sections.
- MCSection *PPA1Section = nullptr;
- MCSection *PPA2Section = nullptr;
- MCSection *PPA2ListSection = nullptr;
- MCSection *ADASection = nullptr;
+ MCSection *RootSDSection = nullptr;
uweigand wrote:
Do we really need this, or could we use TextSection->getParent() when needed?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -239,6 +298,63 @@ class GOFFWriter {
GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
: OS(OS), Asm(Asm) {}
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+ if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+ Section.getSDAttributes());
+writeSymbol(SD);
+ }
+
+ if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+ ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+ }
+
+ if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {
uweigand wrote:
But if you do call an external function, don't you then have to have actual
data in the ADA identifying that external function? I.e. don't those places
that require a non-null ADA also automatically imply there are contents?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -239,6 +298,63 @@ class GOFFWriter {
GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
: OS(OS), Asm(Asm) {}
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+ if (Section.isSD()) {
+GOFFSymbol SD(Section.getName(), Section.getId(),
+ Section.getSDAttributes());
+writeSymbol(SD);
+ }
+
+ if (Section.isED()) {
+GOFFSymbol ED(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getEDAttributes());
+if (Section.requiresLength())
+ ED.SectionLength = Asm.getSectionAddressSize(Section);
+writeSymbol(ED);
+ }
+
+ if (Section.isPR()) {
+GOFFSymbol PR(Section.getName(), Section.getId(),
+ Section.getParent()->getId(), Section.getPRAttributes());
+PR.SectionLength = Asm.getSectionAddressSize(Section);
+if (Section.requiresNonZeroLength()) {
uweigand wrote:
This is also unclear to me. What are the actual rules? Is is that PR
sections of size zero are generally not allowed? Then why do we need an extra
flag here?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
uweigand wrote:
Just to double-check: your current code does *not* set Amode on the PR symbol.
Is is necessary to do this or not?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
uweigand wrote:
I see. This is not currently reflected in the HLASM output, however. How
would one do this?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,145 @@
+//===- MCSectionGOFF.cpp - GOFF Code Section Representation
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/MC/MCSectionGOFF.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace llvm;
+
+namespace {
+void emitRMode(raw_ostream &OS, GOFF::ESDRmode Rmode, bool UseParenthesis) {
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << "RMODE" << (UseParenthesis ? '(' : ' ');
+switch (Rmode) {
+case GOFF::ESD_RMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_RMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_RMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_RMODE_None:
+ break;
+}
+if (UseParenthesis)
+ OS << ')';
+ }
+}
+
+void emitCATTR(raw_ostream &OS, StringRef Name, StringRef ParentName,
+ bool EmitAmodeAndRmode, GOFF::ESDAmode Amode,
+ GOFF::ESDRmode Rmode, GOFF::ESDAlignment Alignment,
+ GOFF::ESDLoadingBehavior LoadBehavior,
+ GOFF::ESDExecutable Executable, bool IsReadOnly,
+ StringRef PartName) {
+ if (EmitAmodeAndRmode && Amode != GOFF::ESD_AMODE_None) {
+OS << ParentName << " AMODE ";
+switch (Amode) {
+case GOFF::ESD_AMODE_24:
+ OS << "24";
+ break;
+case GOFF::ESD_AMODE_31:
+ OS << "31";
+ break;
+case GOFF::ESD_AMODE_ANY:
+ OS << "ANY";
+ break;
+case GOFF::ESD_AMODE_64:
+ OS << "64";
+ break;
+case GOFF::ESD_AMODE_MIN:
+ OS << "ANY64";
+ break;
+case GOFF::ESD_AMODE_None:
+ break;
+}
+OS << "\n";
+ }
+ if (EmitAmodeAndRmode && Rmode != GOFF::ESD_RMODE_None) {
+OS << ParentName << ' ';
+emitRMode(OS, Rmode, /*UseParenthesis=*/false);
+OS << "\n";
+ }
+ OS << Name << " CATTR ";
+ OS << "ALIGN(" << static_cast(Alignment) << ")";
+ switch (LoadBehavior) {
+ case GOFF::ESD_LB_Deferred:
+OS << ",DEFLOAD";
+break;
+ case GOFF::ESD_LB_NoLoad:
+OS << ",NOLOAD";
+break;
+ default:
+break;
+ }
+ switch (Executable) {
+ case GOFF::ESD_EXE_CODE:
+OS << ",EXECUTABLE";
+break;
+ case GOFF::ESD_EXE_DATA:
+OS << ",NOTEXECUTABLE";
+break;
+ default:
+break;
+ }
+ if (IsReadOnly)
+OS << ",READONLY";
+ if (Rmode != GOFF::ESD_RMODE_None) {
+OS << ',';
+emitRMode(OS, Rmode, /*UseParenthesis=*/true);
+ }
+ if (!PartName.empty())
+OS << ",PART(" << PartName << ")";
+ OS << '\n';
+}
+} // namespace
+
+void MCSectionGOFF::printSwitchToSection(const MCAsmInfo &MAI, const Triple &T,
+ raw_ostream &OS,
+ uint32_t Subsection) const {
+ switch (SymbolType) {
+ case GOFF::ESD_ST_SectionDefinition: {
+OS << Name << " CSECT\n";
+Emitted = true;
+break;
+ }
+ case GOFF::ESD_ST_ElementDefinition: {
+bool ParentEmitted = getParent()->Emitted;
+getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, Name, getParent()->getName(), !ParentEmitted,
+EDAttributes.Amode, EDAttributes.Rmode, EDAttributes.Alignment,
+EDAttributes.LoadBehavior, EDAttributes.Executable,
+EDAttributes.IsReadOnly, StringRef());
+ Emitted = true;
+} else
+ OS << Name << " CATTR ,\n";
+break;
+ }
+ case GOFF::ESD_ST_PartReference: {
+MCSectionGOFF *ED = getParent();
+bool SDEmitted = ED->getParent()->Emitted;
+ED->getParent()->printSwitchToSection(MAI, T, OS, Subsection);
+if (!Emitted) {
+ emitCATTR(OS, ED->getName(), ED->getParent()->getName(), !SDEmitted,
+PRAttributes.Amode, getParent()->EDAttributes.Rmode,
+PRAttributes.Alignment, getParent()->EDAttributes.LoadBehavior,
uweigand wrote:
The HLASM docs contain the somewhat cryptic statement: "Binding attributes
assigned to the class are also assigned to the part." where is not really
defined anywhere (I can see) what exactly "binding attributes" mean.
Do we need to replicate the HLASM behavior of setting Amode and LoadBehavior or
not?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+ bool IsRenamable = false;
+ bool IsReadOnly = false; // Not documented.
uweigand wrote:
Does it ever make sense for this value to differ from the ED value? Or is this
one of those attributes that should be copied from the element to the part?
It doesn't seem possible to specific differing values in HLASM ...
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+ bool IsRenamable = false;
+ bool IsReadOnly = false; // Not documented.
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Byte;
uweigand wrote:
Same question for the alignment, can it ever differ from the ED alignment?
How would you specify this in HLASM?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -223,13 +197,95 @@ void GOFFOstream::finalizeRecord() {
}
namespace {
+// A GOFFSymbol holds all the data required for writing an ESD record.
+class GOFFSymbol {
+public:
+ std::string Name;
+ uint32_t EsdId;
+ uint32_t ParentEsdId;
+ uint64_t Offset = 0; // Offset of the symbol into the section. LD only.
+ // Offset is only 32 bit, the larger type is used to
+ // enable error checking.
+ GOFF::ESDSymbolType SymbolType;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_ProgramManagementBinder;
+
+ GOFF::BehavioralAttributes BehavAttrs;
+ GOFF::SymbolFlags SymbolFlags;
+ uint32_t SortKey = 0;
+ uint32_t SectionLength = 0;
+ uint32_t ADAEsdId = 0;
+ uint32_t EASectionEDEsdId = 0;
+ uint32_t EASectionOffset = 0;
+ uint8_t FillByteValue = 0;
+
+ GOFFSymbol() : EsdId(0), ParentEsdId(0) {}
+
+ GOFFSymbol(StringRef Name, uint32_t EsdID, const GOFF::SDAttr &Attr)
+ : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(0),
+SymbolType(GOFF::ESD_ST_SectionDefinition) {
+BehavAttrs.setTaskingBehavior(Attr.TaskingBehavior);
+BehavAttrs.setBindingScope(Attr.BindingScope);
+ }
+
+ GOFFSymbol(StringRef Name, uint32_t EsdID, uint32_t ParentEsdID,
+ const GOFF::EDAttr &Attr)
+ : Name(Name.data(), Name.size()), EsdId(EsdID), ParentEsdId(ParentEsdID),
+SymbolType(GOFF::ESD_ST_ElementDefinition) {
+this->NameSpace = Attr.NameSpace;
+// TODO Do we need/should set the "mangled" flag?
+SymbolFlags.setFillBytePresence(1);
uweigand wrote:
Oh, and one more thing here: by hard-coding this here, we're not emitting any
HLASM output. Should we emit a CATTR FILL(0) then as well? (But that's only
supported on the PART apparently, while the fill byte is supposed to go on the
ED?)
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
https://github.com/uweigand commented: Why do we need all that "virtual section" stuff? Wouldn't it suffice to exit early from ::writeText if the section length is zero? https://github.com/llvm/llvm-project/pull/137235 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
uweigand wrote: Also, the new tests seem to be failing in CI. https://github.com/llvm/llvm-project/pull/137235 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -599,8 +615,23 @@ class MCContext {
unsigned Flags,
unsigned EntrySize);
- MCSectionGOFF *getGOFFSection(StringRef Section, SectionKind Kind,
-MCSection *Parent, uint32_t Subsection = 0);
+private:
+ MCSectionGOFF *getGOFFSection(SectionKind Kind,
+GOFF::ESDSymbolType SymbolType, StringRef Name,
+GOFF::SDAttr SDAttributes,
+GOFF::EDAttr EDAttributes,
+GOFF::PRAttr PRAttributes, MCSection *Parent);
+
+public:
+ MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::SDAttr SDAttributes,
+MCSection *Parent = nullptr);
+ MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::EDAttr EDAttributes,
+MCSection *Parent = nullptr);
+ MCSectionGOFF *getGOFFSection(SectionKind Kind, StringRef Name,
+GOFF::PRAttr PRAttributes,
+MCSection *Parent = nullptr);
uweigand wrote:
On the other hand, ED and PR must have a parent, so it shouldn't default to
nullptr.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [llvm] [release/20.x] Support z17 processor name and scheduler description (PR #135413)
uweigand wrote: > This is a pretty large patch, how safe is this? A lot of this are test and comment-only changes, which should be harmless. Beyond that, the only actual changes are - introduction of the "z17" processor name (three single-line changes) - the new scheduler description (one single complete new file) - this should not cause any functional problems In order of priority, I'd really like to get the "z17" name in; the scheduler description would be good; the rest is just clean-up to keep the sources in line with mainline. https://github.com/llvm/llvm-project/pull/135413 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/20.x: [SystemZ] Fix compile time regression in adjustInliningThreshold(). (#137527) (PR #137628)
https://github.com/uweigand approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/137628 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] release/20.x: [SystemZ] Add header guard macros to vecintrin.h (#129170) (PR #129286)
https://github.com/uweigand approved this pull request. https://github.com/llvm/llvm-project/pull/129286 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/20.x: [SystemZ] Move disabling of arg verification to before isFullyInternal(). (#130693) (PR #130998)
https://github.com/uweigand approved this pull request. https://github.com/llvm/llvm-project/pull/130998 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/20.x: [SystemZ] Move disabling of arg verification to before isFullyInternal(). (#130693) (PR #130998)
uweigand wrote: Fixes a significant compile time regression in LLVM 20, see https://github.com/llvm/llvm-project/issues/130541 https://github.com/llvm/llvm-project/pull/130998 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
uweigand wrote: > I think that splitting the SD/ED/LD into 3 "section"s implies that a > MCSectionGOFF has a fundamentally different semantic than the other > MCSectionXXX. This is something I would like to avoid. On the other hand, the > SD/ED pair is almost the same as an ELF section, so just putting those 2 into > a MCSectionGOFF instance and handling the LD/PR symbol differently makes > sense. Thinking a bit more about this, it looks to me that we should treat SD/ED/PR on the one hand differently from LD (and ER) on the other. The former identify a *range* of address space and may hold contents of those ranges in the form of text records; the latter identify a single address (and hold no content of their own). >From that perspective, the former correspond to the "section" concept, while >the latter correspond to the "symbol" concept. Now, among the section types >SD/ED/PR, GOFF is a bit special in that those are nested - this is somewhat >similar to the subsection concept, but it is explicit in the object file >format (as opposed to, say, ELF subsections). It seems to me that modelling that nested section concept explicitly by creating a separate MCSectionGOFF for each of SD, ED, and PR, and linking them as appropriate via a `Parent` pointer (which we actually already have today!), doesn't look too fundamentally different ... As long as we ensure that text emission happens into the right section (ED or PR as appropriate), this should work fine with common code. In fact, considering that at some point we want to be able to implement a general HLASM AsmParser, which would require handling any allowed combination of CSECT with multiple CATTR, we should *not* merge SD and ED into a single section. (Also, by having them separately, we no longer need special treatment of the "root" SD in the writer.) Finally, having separate MCSession structures for each ESD record may allow using the MCSession::Ordinal field as the ESD ID, which matches its purpose for other object file formats, and which would allow easy resolution of parent (and ADA) section pointers to ESD IDs in the writer. The LD record, on the other hand, clearly should *not* get a MCSectionGOFF. Rather, it would make sense for this to be represented as a MCSymbolGOFF. Specifically, this symbol really represents the implicit section start symbol (which ELF also has!); so it should probably best be emitted not from the section table but from the symbol table. (MCSection already has a `Begin` symbol - it should be possible to use this for that purpose.) That would also unify emission of that type of LD record with the other LD records for "normal" symbols. Attributes associated with the LD record should likewise come from the MCSymbolGOFF. This would include the ADA section, which means that association no longer needs to be hard-coded in the writer, but can instead set up by codegen as appropriate when defining symbols. (E.g. this would also allow handling arbitrary user-provided XATTR PSECT attributes in an HLASM AsmParser.) https://github.com/llvm/llvm-project/pull/133799 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -2759,6 +2760,12 @@ MCSection
*TargetLoweringObjectFileXCOFF::getSectionForLSDA(
//===--===//
TargetLoweringObjectFileGOFF::TargetLoweringObjectFileGOFF() = default;
+void TargetLoweringObjectFileGOFF::getModuleMetadata(Module &M) {
+ // Set the main file name if not set previously by the tool.
+ if (getContext().getMainFileName().empty())
+getContext().setMainFileName(M.getSourceFileName());
uweigand wrote:
Hmm. This sets the common-code "MainFileName", where it otherwise wouldn't be
set. I'm not sure if this is causing any problems - but it would be a place
where we behave differently than others, which is usually better to avoid ...
If it makes sense in general to default MainFileName to SourceFileName when
compiling a module, maybe that could and should be done in common code.
Otherwise, could we instead set the name to MainFileName (as default) in
initGOFFMCObjectFileInfo, and then override to SourceFileName here (if empty)?
Probably need to hold the Root/Ada names as members of TLOF then.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -239,6 +309,102 @@ class GOFFWriter {
GOFFWriter::GOFFWriter(raw_pwrite_stream &OS, MCAssembler &Asm)
: OS(OS), Asm(Asm) {}
+GOFFSymbol GOFFWriter::createGOFFSymbol(StringRef Name, const GOFF::SDAttr
&Attr) {
+ return GOFFSymbol(Name, ++EsdIdCounter, Attr);
+}
+
+GOFFSymbol GOFFWriter::createGOFFSymbol(StringRef Name, const GOFF::EDAttr
&Attr,
+uint32_t ParentEsdId) {
+ return GOFFSymbol(Name, ++EsdIdCounter, ParentEsdId, Attr);
+}
+
+GOFFSymbol GOFFWriter::createGOFFSymbol(StringRef Name, const GOFF::LDAttr
&Attr,
+uint32_t ParentEsdId) {
+ return GOFFSymbol(Name, ++EsdIdCounter, ParentEsdId, Attr);
+}
+
+GOFFSymbol GOFFWriter::createGOFFSymbol(StringRef Name, const GOFF::PRAttr
&Attr,
+uint32_t ParentEsdId) {
+ return GOFFSymbol(Name, ++EsdIdCounter, ParentEsdId, Attr);
+}
+
+void GOFFWriter::defineRootSymbol(const MCSectionGOFF *Text) {
+ // There is always a text section except for DWARF unit tests, so be lenient.
+ GOFFSymbol RootSD =
+ Text ? createGOFFSymbol(Text->getSDName(), Text->getSDAttributes())
+ : createGOFFSymbol("", GOFF::SDAttr{GOFF::ESD_TA_Unspecified,
+ GOFF::ESD_BSC_Unspecified});
+ writeSymbol(RootSD);
+ RootSDEsdId = RootSD.EsdId;
+}
+
+void GOFFWriter::defineSectionSymbols(const MCSectionGOFF &Section) {
+uint32_t SDEsdId = RootSDEsdId;
+if (!Section.usesRootSD()) {
+ GOFFSymbol SD =
+ createGOFFSymbol(Section.getSDName(), Section.getSDAttributes());
+ SDEsdId = SD.EsdId;
+ writeSymbol(SD);
+}
+
+GOFFSymbol ED = createGOFFSymbol(Section.getEDName(),
+ Section.getEDAttributes(), SDEsdId);
+if ((!Section.hasLD() && !Section.hasPR()) || Section.hasLD()) {
+ ED.SectionLength = Asm.getSectionAddressSize(Section);
+}
+writeSymbol(ED);
+
+if (Section.hasLD()) {
+ GOFFSymbol LD = createGOFFSymbol(Section.getLDorPRName(),
+ Section.getLDAttributes(), ED.EsdId);
+ if (Section.isText())
+LD.ADAEsdId = ADAEsdId;
+ writeSymbol(LD);
+}
+
+if (Section.hasPR()) {
+ GOFFSymbol PR = createGOFFSymbol(Section.getLDorPRName(),
+ Section.getPRAttributes(), ED.EsdId);
+ PR.SectionLength = Asm.getSectionAddressSize(Section);
+ if (Section.getName() == ".ada") {
uweigand wrote:
I don't think this name will ever match with the latest code. In any case,
this is really not the proper place to put this kind of decision logic ... that
should really be handled elsewhere (or more generically), I think.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -2767,15 +2774,55 @@ MCSection
*TargetLoweringObjectFileGOFF::getExplicitSectionGlobal(
MCSection *TargetLoweringObjectFileGOFF::getSectionForLSDA(
const Function &F, const MCSymbol &FnSym, const TargetMachine &TM) const {
std::string Name = ".gcc_exception_table." + F.getName().str();
- return getContext().getGOFFSection(Name, SectionKind::getData(), nullptr, 0);
+ constexpr bool Is64Bit = true;
+ constexpr bool UsesXPLINK = true;
uweigand wrote:
These are of course always true in the current upstream code base. I'm not
sure it makes sense to add support for features not (currently) usable upstream
...
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
uweigand wrote: > I implemented the suggestion from @uweigand. The GOFF attributes are set > directly at the `MCSectionGOFF`, and the `GOFFSymbolMapper` is gone. I still > need to update a couple of tests, since now the section names have changed. Thanks, I actually like this better. Looking at the current state, I'm wondering if this could be simplified even further: couldn't we simply allocate separate MCSectionGOFF objects for each of the SD / ED / PR (and possibly LD, but that's maybe really rather a label instead of a section?) symbols? Then each of those could have its own name (there'd probably still have to be a synthesized name to avoid dupliation?) and attributes, and then a "parent" link to identify the containing section. During emission, we could follow those links to ensure the proper numbering and ordering. Or even simpler, we might be able to assign the ID numbers already in the MCSectionGOFF, similar to how the UniqueID is handled for MCSectionELF. Finally, this would allow representing the ADA link explicitly, without having to impose a particular policy in the low-level writer. Does this make sense or am I missing something here? https://github.com/llvm/llvm-project/pull/133799 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
uweigand wrote: Huh. Looks like the new test case now fails ... https://github.com/llvm/llvm-project/pull/137235 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
@@ -50,26 +53,26 @@ class MCSectionGOFF final : public MCSection {
friend class MCContext;
friend class MCSymbolGOFF;
- MCSectionGOFF(StringRef Name, SectionKind K, GOFF::SDAttr SDAttributes,
-MCSectionGOFF *Parent)
- : MCSection(SV_GOFF, Name, K.isText(), /*IsVirtual=*/false, nullptr),
+ MCSectionGOFF(StringRef Name, SectionKind K, bool IsVirtual,
uweigand wrote:
It's not actually about BSS (those are named BSS - but they're not virtual).
The "virtual" marker is for sections that represent those GOFF symbols that do
not themselves contain text, but have nested GOFF sections which do. For
example the section representing a SD GOFF section does not contain text
directly, but it does contain ED sections; and sections representing a ED
symbol with the merge attribute do not contain text directly, but contain PR
sections.
https://github.com/llvm/llvm-project/pull/137235
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
@@ -571,7 +571,6 @@ void MCObjectFileInfo::initGOFFMCObjectFileInfo(const
Triple &T) {
GOFF::ESD_LB_Initial, GOFF::ESD_RQ_0,
GOFF::ESD_ALIGN_Doubleword, 0},
RootSDSection);
-
uweigand wrote:
This change is spurious now.
https://github.com/llvm/llvm-project/pull/137235
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
https://github.com/uweigand approved this pull request. LGTM now, thanks! https://github.com/llvm/llvm-project/pull/137235 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
https://github.com/uweigand edited https://github.com/llvm/llvm-project/pull/137235 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [release/20.x] Update release notes for SystemZ changes (PR #140060)
https://github.com/uweigand created https://github.com/llvm/llvm-project/pull/140060 None >From c97e80756a221267af0faebafaa956674f49d732 Mon Sep 17 00:00:00 2001 From: Ulrich Weigand Date: Thu, 15 May 2025 16:00:30 +0200 Subject: [PATCH] Update release notes for SystemZ changes --- llvm/docs/ReleaseNotes.md | 9 + 1 file changed, 9 insertions(+) diff --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md index f34003eaf0fe2..ef4ec9b56f364 100644 --- a/llvm/docs/ReleaseNotes.md +++ b/llvm/docs/ReleaseNotes.md @@ -349,6 +349,15 @@ Changes to the RISC-V Backend extension. * Added ``Sdext`` and ``Sdtrig`` extensions. +Changes to the SystemZ Backend +-- + +* Added support for the IBM z17 processor and the arch15 cpu architecture. +* Added support for `__builtin_setjump` and `__builtin_longjmp`. +* Improve inlining heuristics to fix compile time explosion in certain cases. +* Improve various cost functions. +* Improve compatibility of the assembler parser with the GNU assembler. + Changes to the WebAssembly Backend -- ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
https://github.com/uweigand edited https://github.com/llvm/llvm-project/pull/133799 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
uweigand wrote:
Like above, right now there doesn't appear to be any code to emit LD symbols to
asm output.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of text records (PR #137235)
https://github.com/uweigand approved this pull request. Still LGTM. https://github.com/llvm/llvm-project/pull/137235 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
https://github.com/uweigand commented: Looks generally good to me now, still a few comments inline. https://github.com/llvm/llvm-project/pull/133799 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
uweigand wrote:
This comment doesn't match the current implementation any more.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Emit symbols for functions. (PR #144437)
https://github.com/uweigand commented: There doesn't appear to be any asm output for these? https://github.com/llvm/llvm-project/pull/144437 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,113 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDAmode Amode;
uweigand wrote:
OK, thanks for checking. Right now Amode is nowhere emitted to asm output at
all anymore, but I guess that's because there is no asm output for LD symbols
(function labels). I assume this will be added later?
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
@@ -0,0 +1,106 @@
+//===- MCGOFFAttributes.h - Attributes of GOFF symbols
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Defines the various attribute collections defining GOFF symbols.
+//
+//===--===//
+
+#ifndef LLVM_MC_MCGOFFATTRIBUTES_H
+#define LLVM_MC_MCGOFFATTRIBUTES_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/GOFF.h"
+#include
+
+namespace llvm {
+namespace GOFF {
+// An "External Symbol Definition" in the GOFF file has a type, and depending
on
+// the type a different subset of the fields is used.
+//
+// Unlike other formats, a 2 dimensional structure is used to define the
+// location of data. For example, the equivalent of the ELF .text section is
+// made up of a Section Definition (SD) and a class (Element Definition; ED).
+// The name of the SD symbol depends on the application, while the class has
the
+// predefined name C_CODE/C_CODE64 in AMODE31 and AMODE64 respectively.
+//
+// Data can be placed into this structure in 2 ways. First, the data (in a text
+// record) can be associated with an ED symbol. To refer to data, a Label
+// Definition (LD) is used to give an offset into the data a name. When
binding,
+// the whole data is pulled into the resulting executable, and the addresses
+// given by the LD symbols are resolved.
+//
+// The alternative is to use a Part Definition (PR). In this case, the data (in
+// a text record) is associated with the part. When binding, only the data of
+// referenced PRs is pulled into the resulting binary.
+//
+// Both approaches are used, which means that the equivalent of a section in
ELF
+// results in 3 GOFF symbols, either SD/ED/LD or SD/ED/PR. Moreover, certain
+// sections are fine with just defining SD/ED symbols. The SymbolMapper takes
+// care of all those details.
+
+// Attributes for SD symbols.
+struct SDAttr {
+ GOFF::ESDTaskingBehavior TaskingBehavior = GOFF::ESD_TA_Unspecified;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for ED symbols.
+struct EDAttr {
+ bool IsReadOnly = false;
+ GOFF::ESDRmode Rmode;
+ GOFF::ESDNameSpaceId NameSpace = GOFF::ESD_NS_NormalName;
+ GOFF::ESDTextStyle TextStyle = GOFF::ESD_TS_ByteOriented;
+ GOFF::ESDBindingAlgorithm BindAlgorithm = GOFF::ESD_BA_Concatenate;
+ GOFF::ESDLoadingBehavior LoadBehavior = GOFF::ESD_LB_Initial;
+ GOFF::ESDReserveQwords ReservedQwords = GOFF::ESD_RQ_0;
+ GOFF::ESDAlignment Alignment = GOFF::ESD_ALIGN_Doubleword;
+ uint8_t FillByteValue = 0;
+};
+
+// Attributes for LD symbols.
+struct LDAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDBindingStrength BindingStrength = GOFF::ESD_BST_Strong;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDAmode Amode;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+};
+
+// Attributes for PR symbols.
+struct PRAttr {
+ bool IsRenamable = false;
+ GOFF::ESDExecutable Executable = GOFF::ESD_EXE_Unspecified;
+ GOFF::ESDLinkageType Linkage = GOFF::ESD_LT_XPLink;
+ GOFF::ESDBindingScope BindingScope = GOFF::ESD_BSC_Unspecified;
+ uint32_t SortKey = 0;
+};
+
+// Class names and other values depending on AMODE64 or AMODE31, and other
+// environment properties. For now, only the 64 bit XPLINK case is defined.
+
+// GOFF classes.
+constexpr StringLiteral CLASS_CODE = "C_CODE64";
+constexpr StringLiteral CLASS_WSA = "C_WSA64";
+constexpr StringLiteral CLASS_DATA = "C_DATA64";
+constexpr StringLiteral CLASS_PPA2 = "C_@@QPPA2";
+
+// Addres and residency mode.
+constexpr GOFF::ESDAmode AMODE = GOFF::ESD_AMODE_64;
+constexpr GOFF::ESDRmode RMODE = GOFF::ESD_RMODE_64;
+
+// Linkage.
+constexpr GOFF::ESDLinkageType LINKAGE = GOFF::ESD_LT_XPLink;
+
+// Loadding behavior.
+constexpr GOFF::ESDLoadingBehavior LOADBEHAVIOR = GOFF::ESD_LB_Initial;
uweigand wrote:
I'm wondering about the above four constants - it's a bit unclear how they will
help (in the future) to possibly extend the implementation to 31-bit or
non-XPLINK variants, since you'd have to get the mode input from somewhere.
Also, these constants aren't used systematically, e.g. a few places use LINKAGE
but others hard-coded ESD_LT_XPLink anyway.
https://github.com/llvm/llvm-project/pull/133799
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [GOFF] Add writing of section symbols (PR #133799)
https://github.com/uweigand approved this pull request. This version looks good to me now, thanks! https://github.com/llvm/llvm-project/pull/133799 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] SystemZ: Add sincos intrinsic test (PR #147473)
uweigand wrote: > The ZOS run line is mostly broken. update_test_checks seems to not work on it > and I have no idea what I'm looking at here. It's not obvious to me what the > calls are. I added some checks for the references to the libcalls printed at > the end of the module, but didn't check anything in the function body. half > also just asserts somewhere. `half` is not currently implemented on z/OS. On Linux, your half tests work for me. In general, you probably don't need to bother with a z/OS test at this point, there's still too many open issues. @redstar this is something to put on the list to add a z/OS test case later. https://github.com/llvm/llvm-project/pull/147473 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
