[llvm][DFP] Add support for DFP encoding in llvm::DataLayout. #40

zahiraam · 2023-12-06T16:41:13Z

This patch implements the support to record the DFP encoding of a TU.

Note: this is a draft patch and implements the support for x86 targets only.

I have made the changes here assuming that we are taking into account the language option -fexperimental-decimal-floating-point. Is that the right thing to do or should we just set up the new datalayout regardless of the use of this option?

I haven't thought of about compatibility issues that might arise with modified target datalayout.

tahonermann · 2023-12-20T16:31:04Z

clang/include/clang/Basic/TargetOptions.h

+  enum class BinaryEncoding { BID, DPD, None };
+  BinaryEncoding DFPEncoding = BinaryEncoding::None;


We already have something similar in the TargetInfo.h header as shown below. I still haven't been able to get a good understanding for when TargetInfo is used vs TargetOptions. Can you look to see if it makes sense to use the data already present in TargetInfo?

enum class DecimalFloatMode : uint8_t { BID, // Binary Integer Decimal. DPD, // Densely Packed Decimal. }; ... class TargetInfo : public TransferrableTargetInfo, public RefCountedBase<TargetInfo> { ... // If disengaged, decimal floating-point extensions are not supported, // otherwise, the decimal floating-point mode that is enabled. std::optional<DecimalFloatMode> DecimalFloatEnablementAndMode; ... };

I mentioned this in the chat earlier today, but it should probably go in include/llvm/ADT/FloatingPointMode.h, which contains the other FP env modes.

Thank you, yes, that looks exactly right.

Moved the enum to FloatingPointMode.h. Tried to rest into TargetInfo but that doesn't seem to work. It needs to be in clang::TargetOptions. The reason being that in initTargetOptions we are passing the info from clang::TargetOptions to llvm::TargetOptions and there is no access to TargetInfo here. So the info about the encoding needs to reside in targetOptions. Will keep looking at it.

tahonermann · 2023-12-20T16:33:31Z

clang/lib/Basic/Targets/X86.h

+    bool isBIDEncoding = Opts.DFPEncoding == TargetOptions::BinaryEncoding::BID;
+    bool isDPDEncoding = Opts.DFPEncoding == TargetOptions::BinaryEncoding::DPD;


At present, this information should already be available on the TargetInfo base class via the DecimalFloatEnablementAndMode member at this point (if hasDecimalFloatingPoint() returns true, then getDecimalFloatingPointMode() will return the active DFP mode).

See comment above.

tahonermann · 2023-12-20T16:36:59Z

clang/lib/Basic/Targets/X86.h

+    if (isBIDEncoding)
+      resetDataLayout(
+          IsX32       ? "e-d:-bid-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-"
+                        "i64:64-f80:128-n8:16:32:64-S128"
+          : IsWinCOFF ? "e-d:bid-m:w-p270:32:32-p271:32:32-p272:64:"
+                        "64-i64:64-f80:128-n8:16:32:64-S128"
+                      : "e-d:bid-m:e-p270:32:32-p271:32:32-p272:64:"
+                        "64-i64:64-f80:128-n8:16:32:64-S128");
+    else if (isDPDEncoding)
+      resetDataLayout(
+          IsX32       ? "e-d:dpd-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-"
+                        "i64:64-f80:128-n8:16:32:64-S128"
+          : IsWinCOFF ? "e-d:dpd-m:w-p270:32:32-p271:32:32-p272:64:"
+                        "64-i64:64-f80:128-n8:16:32:64-S128"
+                      : "e-d:dpd-m:e-p270:32:32-p271:32:32-p272:64:"
+                        "64-i64:64-f80:128-n8:16:32:64-S128");
+    else
+      resetDataLayout(IsX32 ? "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-"
+                              "i64:64-f80:128-n8:16:32:64-S128"
+                      : IsWinCOFF ? "e-m:w-p270:32:32-p271:32:32-p272:64:"
+                                    "64-i64:64-f80:128-n8:16:32:64-S128"
+                                  : "e-m:e-p270:32:32-p271:32:32-p272:64:"
+                                    "64-i64:64-f80:128-n8:16:32:64-S128");


Rather than duplicating the existing strings, I think this could be simplified with some string building. See the WindowsX86_32TargetInfo constructor later in this same file for an example.

tahonermann · 2023-12-20T16:42:58Z

clang/lib/CodeGen/BackendUtil.cpp

+  if (TargetOpts.DFPEncoding == clang::TargetOptions::BinaryEncoding::BID)
+    Options.DFPEncoding = llvm::BinaryEncoding::BID;
+  else if (TargetOpts.DFPEncoding == clang::TargetOptions::BinaryEncoding::DPD)
+    Options.DFPEncoding = llvm::BinaryEncoding::DPD;
+  else
+    Options.DFPEncoding = llvm::BinaryEncoding::None;
+


Hmm, this suggests that the enumeration that is currently defined in clang/include/clang/Basic/TargetInfo.h should get moved to llvm/include/llvm/Target/TargetOptions.h. Or perhaps should be incorporated into APFloatBase in llvm/include/llvm/ADT/APFloat.h. What do you think?

Exactly what I have done :-) Not sure about APFloat.h. I will take a look. For now it's residing here.

tahonermann · 2023-12-20T16:46:18Z

clang/lib/Frontend/CompilerInstance.cpp

+  if (getLangOpts().DecimalFloatingPoint) {
+    if (getInvocation().getTargetOpts().CPU == "x86" ||
+        getInvocation().getTargetOpts().CPU == "x86-64")
+      getInvocation().getTargetOpts().DFPEncoding =
+          TargetOptions::BinaryEncoding::BID;
+    else
+      getInvocation().getTargetOpts().DFPEncoding =
+          TargetOptions::BinaryEncoding::DPD;
+  }


This should be addressed by the code changes I've been taking forever to finish. There is already code that does similarly to populate TargetInfo::DecimalFloatEnablementAndMode; see the assignment to DecimalFloatEnablementAndMode in clang/lib/Basic/Targets/OSTargets.h.

tahonermann · 2023-12-20T16:56:21Z

llvm/lib/Target/X86/X86TargetMachine.cpp

+  // Decimal floating-point encoding.
+  if (Options.DFPEncoding != BinaryEncoding::None) {
+    assert(Options.DFPEncoding == BinaryEncoding::BID &&
+           "Decimal floating-point on x86 is BID!");
+    Ret += "-d:bid";
+  }
+


There are multiple places where these strings have to be built for each target? That seems very unfortunate.

jcranmer-intel

This also needs changes in the LangRef.rst for LLVM IR to document the data layout string changes.

jcranmer-intel · 2023-12-20T19:29:27Z

clang/include/clang/Basic/TargetOptions.h

+  enum class BinaryEncoding { BID, DPD, None };
+  BinaryEncoding DFPEncoding = BinaryEncoding::None;


I mentioned this in the chat earlier today, but it should probably go in include/llvm/ADT/FloatingPointMode.h, which contains the other FP env modes.

jcranmer-intel · 2023-12-20T19:44:08Z

clang/lib/Frontend/CompilerInstance.cpp

+        getInvocation().getTargetOpts().CPU == "x86-64")
+      getInvocation().getTargetOpts().DFPEncoding =
+          TargetOptions::BinaryEncoding::BID;
+    else


I don't know that this logic is correct for most targets.

libdfp only mentions x86(-64), PPC and s390 in its documentation (see https://github.com/libdfp/libdfp), but helpfully, the most recent commit suggests that aarch64 is going to go with BID.

The AArch64 suggests that it's using BID: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#decimal-floating-point (there's nothing corresponding I could find for 32-bit arm).

It isn't right. I suspect Zahira derived this from similar code I added to the LinuxTargetInfo constructor in clang/lib/Basic/Targets/OSTargets.h. I'm still working on code to enable proper target dependent enablement. I've been taking forever to get that done.

I think our plan for prior to upstreaming should be to focus on just Intel support (perhaps IBM too given Ariel's involvement) and then let maintainers for other architectures enable support for other targets following appropriate testing after our changes are accepted upstream.

Again the change you are suggesting implies that the encoding info is in TargetInfo but I don't think we can do that there. See comments above.

tahonermann · 2023-12-21T22:16:04Z

Per discussion in the DFP meeting we had yesterday, I think we want to hold off on merging this until I finally complete the target configuration and enablement work I've been doing.

zahiraam · 2024-01-30T21:29:11Z

Here is an other round of the code. It's certainly not done. May be not all comments were raised but that's not because I ignore them but it's either because it's WIP or I didn't see a way to do it.
In general it would be better if the encoding info resided in TargetInfo but it seems it can't be done because the passage of to llvm side is done via the TargetOptions.

@0

…lvm#80904)" This reverts commit b1ac052. This commit breaks coroutine splitting for non-swift calling convention functions. In this example: ```ll ; ModuleID = 'repro.ll' source_filename = "stdlib/test/runtime/test_llcl.mojo" target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @0 = internal constant { i32, i32 } { i32 trunc (i64 sub (i64 ptrtoint (ptr @craSH to i64), i64 ptrtoint (ptr getelementptr inbounds ({ i32, i32 }, ptr @0, i32 0, i32 1) to i64)) to i32), i32 64 } define dso_local void @af_suspend_fn(ptr %0, i64 %1, ptr %2) #0 { ret void } define dso_local void @craSH(ptr %0) #0 { %2 = call token @llvm.coro.id.async(i32 64, i32 8, i32 0, ptr @0) %3 = call ptr @llvm.coro.begin(token %2, ptr null) %4 = getelementptr inbounds { ptr, { ptr, ptr }, i64, { ptr, i1 }, i64, i64 }, ptr poison, i32 0, i32 0 %5 = call ptr @llvm.coro.async.resume() store ptr %5, ptr %4, align 8 %6 = call { ptr, ptr, ptr } (i32, ptr, ptr, ...) @llvm.coro.suspend.async.sl_p0p0p0s(i32 0, ptr %5, ptr @ctxt_proj_fn, ptr @af_suspend_fn, ptr poison, i64 -1, ptr poison) ret void } define dso_local ptr @ctxt_proj_fn(ptr %0) #0 { ret ptr %0 } ; Function Attrs: nomerge nounwind declare { ptr, ptr, ptr } @llvm.coro.suspend.async.sl_p0p0p0s(i32, ptr, ptr, ...) #1 ; Function Attrs: nounwind declare token @llvm.coro.id.async(i32, i32, i32, ptr) #2 ; Function Attrs: nounwind declare ptr @llvm.coro.begin(token, ptr writeonly) #2 ; Function Attrs: nomerge nounwind declare ptr @llvm.coro.async.resume() #1 attributes #0 = { "target-features"="+adx,+aes,+avx,+avx2,+bmi,+bmi2,+clflushopt,+clwb,+clzero,+crc32,+cx16,+cx8,+f16c,+fma,+fsgsbase,+fxsr,+invpcid,+lzcnt,+mmx,+movbe,+mwaitx,+pclmul,+pku,+popcnt,+prfchw,+rdpid,+rdpru,+rdrnd,+rdseed,+sahf,+sha,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,+ssse3,+vaes,+vpclmulqdq,+wbnoinvd,+x87,+xsave,+xsavec,+xsaveopt,+xsaves" } attributes #1 = { nomerge nounwind } attributes #2 = { nounwind } ``` This verifier crashes after the `coro-split` pass with ``` cannot guarantee tail call due to mismatched parameter counts musttail call void @af_suspend_fn(ptr poison, i64 -1, ptr poison) LLVM ERROR: Broken function PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: opt ../../../reduced.ll -O0 #0 0x00007f1d89645c0e __interceptor_backtrace.part.0 /build/gcc-11-XeT9lY/gcc-11-11.4.0/build/x86_64-linux-gnu/libsanitizer/asan/../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4193:28 #1 0x0000556d94d254f7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22 #2 0x0000556d94d19a2f llvm::sys::RunSignalHandlers() /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Signals.cpp:105:20 #3 0x0000556d94d1aa42 SignalHandler(int) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Unix/Signals.inc:371:36 #4 0x00007f1d88e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x00007f1d88e969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #6 0x00007f1d88e969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #7 0x00007f1d88e969fc pthread_kill ./nptl/pthread_kill.c:89:10 #8 0x00007f1d88e42476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #9 0x00007f1d88e287f3 abort ./stdlib/abort.c:81:7 #10 0x0000556d8944be01 std::vector<llvm::json::Value, std::allocator<llvm::json::Value>>::size() const /usr/include/c++/11/bits/stl_vector.h:919:40 #11 0x0000556d8944be01 bool std::operator==<llvm::json::Value, std::allocator<llvm::json::Value>>(std::vector<llvm::json::Value, std::allocator<llvm::json::Value>> const&, std::vector<llvm::json::Value, std::allocator<llvm::json::Value>> const&) /usr/include/c++/11/bits/stl_vector.h:1893:23 #12 0x0000556d8944be01 llvm::json::operator==(llvm::json::Array const&, llvm::json::Array const&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/Support/JSON.h:572:69 #13 0x0000556d8944be01 llvm::json::operator==(llvm::json::Value const&, llvm::json::Value const&) (.cold) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/JSON.cpp:204:28 #14 0x0000556d949ed2bd llvm::report_fatal_error(char const*, bool) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/ErrorHandling.cpp:82:70 #15 0x0000556d8e37e876 llvm::SmallVectorBase<unsigned int>::size() const /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:91:32 #16 0x0000556d8e37e876 llvm::SmallVectorTemplateCommon<llvm::DiagnosticInfoOptimizationBase::Argument, void>::end() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:282:41 #17 0x0000556d8e37e876 llvm::SmallVector<llvm::DiagnosticInfoOptimizationBase::Argument, 4u>::~SmallVector() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:1215:24 #18 0x0000556d8e37e876 llvm::DiagnosticInfoOptimizationBase::~DiagnosticInfoOptimizationBase() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:413:7 #19 0x0000556d8e37e876 llvm::DiagnosticInfoIROptimization::~DiagnosticInfoIROptimization() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:622:7 #20 0x0000556d8e37e876 llvm::OptimizationRemark::~OptimizationRemark() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:689:7 #21 0x0000556d8e37e876 operator() /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroSplit.cpp:2213:14 #22 0x0000556d8e37e876 emit<llvm::CoroSplitPass::run(llvm::LazyCallGraph::SCC&, llvm::CGSCCAnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)::<lambda()> > /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/Analysis/OptimizationRemarkEmitter.h:83:12 #23 0x0000556d8e37e876 llvm::CoroSplitPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroSplit.cpp:2212:13 #24 0x0000556d8c36ecb1 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::CoroSplitPass, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #25 0x0000556d91c1a84f llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Analysis/CGSCCPassManager.cpp:90:12 #26 0x0000556d8c3690d1 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #27 0x0000556d91c2162d llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Analysis/CGSCCPassManager.cpp:278:18 #28 0x0000556d8c369035 llvm::detail::PassModel<llvm::Module, llvm::ModuleToPostOrderCGSCCPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #29 0x0000556d9457abc5 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManager.h:247:20 #30 0x0000556d8e30979e llvm::CoroConditionalWrapper::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroConditionalWrapper.cpp:19:74 #31 0x0000556d8c365755 llvm::detail::PassModel<llvm::Module, llvm::CoroConditionalWrapper, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #32 0x0000556d9457abc5 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManager.h:247:20 #33 0x0000556d89818556 llvm::SmallPtrSetImplBase::isSmall() const /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:196:33 #34 0x0000556d89818556 llvm::SmallPtrSetImplBase::~SmallPtrSetImplBase() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:84:17 #35 0x0000556d89818556 llvm::SmallPtrSetImpl<llvm::AnalysisKey*>::~SmallPtrSetImpl() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:321:7 #36 0x0000556d89818556 llvm::SmallPtrSet<llvm::AnalysisKey*, 2u>::~SmallPtrSet() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:427:7 #37 0x0000556d89818556 llvm::PreservedAnalyses::~PreservedAnalyses() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/Analysis.h:109:7 #38 0x0000556d89818556 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/NewPMDriver.cpp:532:10 #39 0x0000556d897e3939 optMain /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/optdriver.cpp:737:27 #40 0x0000556d89455461 main /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/opt.cpp:25:33 #41 0x00007f1d88e29d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #42 0x00007f1d88e29e40 call_init ./csu/../csu/libc-start.c:128:20 #43 0x00007f1d88e29e40 __libc_start_main ./csu/../csu/libc-start.c:379:5 llvm#44 0x0000556d897b6335 _start (/home/ubuntu/modular/.derived/third-party/llvm-project/build-relwithdebinfo-asan/bin/opt+0x150c335) Aborted (core dumped)

zahiraam added 2 commits December 6, 2023 05:27

Add support for DFP encoding in llvm::DataLayout.

7b404ff

Added LIT test.

60a6a1c

zahiraam changed the title ~~Add support for DFP encoding in llvm::DataLayout.~~ [llvm][DFP] Add support for DFP encoding in llvm::DataLayout. Dec 6, 2023

zahiraam added 2 commits December 6, 2023 12:11

Code cleanup.

e4f4016

More cleanup.

ee642f5

zahiraam requested review from tahonermann, jcranmer-intel, shafik and Ariel-Burton December 6, 2023 20:45

tahonermann requested changes Dec 20, 2023

View reviewed changes

jcranmer-intel reviewed Dec 20, 2023

View reviewed changes

zahiraam added 2 commits January 29, 2024 12:30

Addressed review comments.

69e623b

Code cleanup.

e92106f

tahonermann mentioned this pull request Aug 13, 2024

Add support for -mdecimal-float-abi option. #43

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[llvm][DFP] Add support for DFP encoding in llvm::DataLayout. #40

[llvm][DFP] Add support for DFP encoding in llvm::DataLayout. #40

zahiraam commented Dec 6, 2023 •

edited

Loading

tahonermann Dec 20, 2023

jcranmer-intel Dec 20, 2023

tahonermann Dec 21, 2023

zahiraam Jan 30, 2024 •

edited

Loading

tahonermann Dec 20, 2023

zahiraam Jan 30, 2024

tahonermann Dec 20, 2023

tahonermann Dec 20, 2023

zahiraam Jan 30, 2024

tahonermann Dec 20, 2023

tahonermann Dec 20, 2023

jcranmer-intel left a comment

jcranmer-intel Dec 20, 2023

jcranmer-intel Dec 20, 2023

tahonermann Dec 21, 2023

zahiraam Jan 30, 2024

tahonermann commented Dec 21, 2023

zahiraam commented Jan 30, 2024

		enum class BinaryEncoding { BID, DPD, None };
		BinaryEncoding DFPEncoding = BinaryEncoding::None;

		bool isBIDEncoding = Opts.DFPEncoding == TargetOptions::BinaryEncoding::BID;
		bool isDPDEncoding = Opts.DFPEncoding == TargetOptions::BinaryEncoding::DPD;

[llvm][DFP] Add support for DFP encoding in llvm::DataLayout. #40

Are you sure you want to change the base?

[llvm][DFP] Add support for DFP encoding in llvm::DataLayout. #40

Conversation

zahiraam commented Dec 6, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zahiraam Jan 30, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcranmer-intel left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tahonermann commented Dec 21, 2023

zahiraam commented Jan 30, 2024

zahiraam commented Dec 6, 2023 •

edited

Loading

zahiraam Jan 30, 2024 •

edited

Loading