Skip to content

[SYCL][ABI-break] Remove <iostream> headers from "sycl/sycl.hpp" and related files #6337

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 60 commits into from

Conversation

raaiq1
Copy link
Contributor

@raaiq1 raaiq1 commented Jun 21, 2022

Refactored code base to remove dependency from "sycl/sycl.hpp". The main motivation behind it is so confrom by LLVM coding standards (https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden) which forbids the inclusion of <iostream> in library files. This required the following:

  • Replacing cout or cerr or clog statements with fprintf() statements
  • Removing >> , << operators for sycl classes that interact with <iostream> and substituting them with std::string cast operator if possible, otherwise a to_string method was defined (as the case in backend enum)
  • Removing any calls to the operators mentioned above (if a string::cast operator couldn't be defined) and replacing them with printf
  • Refactoring some class methods to take a FILE* instead of an <iostream> object, such as void DeviceBinaryImage::dump(std::ostream &Out) const under ''sycl/include/CL/sycl/detail/pi.hpp" and virtual void Command::printDot(std::ostream &Stream) const = 0; and it's various overloads

@raaiq1 raaiq1 requested review from a team as code owners June 21, 2022 23:58
@raaiq1 raaiq1 requested a review from steffenlarsen June 21, 2022 23:58
@cperkinsintel cperkinsintel self-requested a review June 24, 2022 19:31
@raaiq1 raaiq1 marked this pull request as draft June 24, 2022 21:51
@raaiq1
Copy link
Contributor Author

raaiq1 commented Jul 14, 2022

/verify with intel/llvm-test-suite#1084

@raaiq1
Copy link
Contributor Author

raaiq1 commented Jul 14, 2022

/verify with intel/llvm-test-suite#1084

@raaiq1
Copy link
Contributor Author

raaiq1 commented Jul 15, 2022

/verify with intel/llvm-test-suite#1084

@raaiq1
Copy link
Contributor Author

raaiq1 commented Jul 15, 2022

/verify with intel/llvm-test-suite#1084

1 similar comment
@cperkinsintel
Copy link
Contributor

/verify with intel/llvm-test-suite#1084

@cperkinsintel
Copy link
Contributor

/verify with intel/llvm-test-suite#1084

@raaiq1 raaiq1 changed the title [SYCL][ABI-break] Remove <iostream> headers from "CL/sycl.hpp" and related files [SYCL][ABI-break] Remove <iostream> headers from "sycl/sycl.hpp" and related files Jul 19, 2022
Copy link
Contributor

@cperkinsintel cperkinsintel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@cperkinsintel
Copy link
Contributor

/verify with intel/llvm-test-suite#1084

@cperkinsintel
Copy link
Contributor

ping to other reviewers. The 'Jenkins/llvm-test-suite' is passing against the matching PR intel/llvm-test-suite#1084 on the test suite.

@cperkinsintel
Copy link
Contributor

ping to other reviewers. I know this touches a lot of files, which makes the review a bit of a chore. But also the longer this takes to review and merge, the more likely there will be merge conflicts that'll just set the reviews back. The llvm-test-suite has been updated to match intel/llvm-test-suite#1084 and the "Jenkins/llvm-test-suite" entry in the checks above demonstrates that these are passing.

@@ -116,14 +116,16 @@ static inline std::string codeToString(pi_int32 code) {
"Native API returns: "

#ifndef __SYCL_SUPPRESS_PI_ERROR_REPORT
#include <iostream>
#include <cstdio>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raaiq1, please, add motivation for this change to the PR description. Right now it just describes what PR does, but doesn't explain why do we need this change.

I guess performance has something to do with it. Am I right?
FYI: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slio3-prefer-iostreams-for-io

Copy link
Contributor Author

@raaiq1 raaiq1 Jul 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main motivation behind it to abide by llvm coding standards, in this case it's avoid including <iostream> in library files: https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, add such information to the pull request description. It's important context information for doing code review.

Comment on lines +52 to +53
std::string Out{};
Out += backend_to_string(this->Backend);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
std::string Out{};
Out += backend_to_string(this->Backend);
std::string Out = backend_to_string(this->Backend);

std::string Out{};
Out += backend_to_string(this->Backend);
Out += ":";
switch (this->DeviceType) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just out of curiosity: is this-> really needed here?

Comment on lines +33 to +34
std::string versionString;
versionString = "CUDA ";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
std::string versionString;
versionString = "CUDA ";
std::string versionString = "CUDA ";

@@ -114,7 +115,8 @@ static bool PrintPiTrace = false;

static void PiTrace(std::string TraceString) {
if (PrintPiTrace) {
std::cout << TraceString << std::endl;
printf("%s\n", TraceString.c_str());
fflush(stdout);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to change anything in source files? The PR title says is removed from headers files.

NOTE: in addition to source files we can keep plug-in header files untouched, if we update only header files included into sycl/sycl.hpp.
The same applies to all headers in source directory. They are not included to sycl/sycl.hpp as well.

Copy link
Contributor Author

@raaiq1 raaiq1 Jul 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry the PR title is a little misleading. This does remove <iostream> headers form the source files as well. So according to LLVM coding standards <iostream> headers are forbidden in 'library files' (https://llvm.org/docs/CodingStandards.html#include-iostream-is-forbidden). I interpreted 'library files' to include both the headers and source files. I might be wrong though

Comment on lines +9 to 10
#include <iostream>
#include <sycl/sycl.hpp>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#include <iostream>
#include <sycl/sycl.hpp>
#include <sycl/sycl.hpp>
#include <iostream>

Let's include iostream after sycl.hpp to catch cases when sycl.hpp uses iostream functionality w/o including the header.

@@ -0,0 +1,13 @@
// UNSUPPORTED: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it here?

// RUN: gdb %t.out -batch -x %sycl_gdb_iostream 2>&1 | FileCheck %s
// CHECK: ignore next 9998 hits
//
// Tests if <sycl/sycl.hpp> headers include any <iostream> headers
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it can be done w/o running a GDB, but just checking the compiler output.
NOTE: it checks host side of the compilation only, so you don't need to compile with -fsycl option.

Comment on lines +59 to +61
if (c == '\n') {
return currentIndex;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code above doesn't use braces for one-statement branches. Please, use consistent code style.

Suggested change
if (c == '\n') {
return currentIndex;
}
if (c == '\n')
return currentIndex;

@raaiq1
Copy link
Contributor Author

raaiq1 commented Jul 22, 2022

@bader @cperkinsintel @kbobrovs There is an alternative solution @aelovikov-intel suggested. I've made a draft PR for it (#6469). They both accomplish the same goal but this PR may have some performance improvements but I'm not sure. I would like to discuss if it's better to merge this PR or the draft PR

@bader
Copy link
Contributor

bader commented Jul 24, 2022

@bader @cperkinsintel There is an alternative solution @aelovikov-intel suggested. I've made a draft PR for it (#6469). They both accomplish the same goal but this PR may have some performance improvements but I'm not sure. I would like to discuss if it's better to merge this PR or the draft PR

I think #6469 might be good enough as first step, but eventually it would be great to have some soft of internal logger, which can isolate C or C++ APIs we use to output error/warning/notification information.

#include "dpcpp_logger.h"

ERR(<args>);                  // resolves into std::cerr/clog or fprintf(stderr, ...)
INFO(<args>)/WARN(<args>);    // resolves into std::cout or fprintf(stdout, ...)

I think this can be done with zero run-time overhead (i.e. can as fast as using std::cerr/cout or fprintf directly) and simplify maintenance.

/// Prefix increment, increments elements of this object.
/// @return Reference to this object.
simd &operator++() {
simd &
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please drop this change

@@ -125,9 +125,30 @@ class simd : public detail::simd_obj_impl<
return sycl::ext::oneapi::experimental::simd<Ty, N1>(base_type::data());
}

/// @ingroup sycl_esimd_misc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is wrong doc group. just drop it

@@ -125,9 +125,30 @@ class simd : public detail::simd_obj_impl<
return sycl::ext::oneapi::experimental::simd<Ty, N1>(base_type::data());
}

/// @ingroup sycl_esimd_misc
/// Prints a \c simd object to an output stream.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not what the code is doing now, it rather converts the object to std::string

sprintf(ESimdEmuVersionString, "0.%d.%d", ESIMDEmuPluginInterfaceVersion,
ESIMDEmuPluginDataVersion);
sprintf(ESimdEmuVersionString, "0.%lld.%lld",
(long long int)ESIMDEmuPluginInterfaceVersion,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this change is needed? the *Version are #define's, so %d should work OK - ?

"%s\n"
"The device interface version provided from plug-in"
"library is behind required device interface version\n"
"Found version : %llu\n"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

%llu does not seem to be right for printing uintptr_t. See e.g. https://stackoverflow.com/questions/5795978/string-format-for-intptr-t-and-uintptr-t

@raaiq1 raaiq1 marked this pull request as draft July 25, 2022 20:45
@raaiq1
Copy link
Contributor Author

raaiq1 commented Jul 27, 2022

This PR is being closed, as it touches a lot of files and prone to more errors. An alternative PR has been opened for the simpler solution (#6469)

@raaiq1 raaiq1 closed this Jul 27, 2022
@raaiq1 raaiq1 deleted the raaiq branch August 2, 2022 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants