This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Change OpenCL builtin version encoding
ClosedPublic

Authored by svenvh on Apr 14 2021, 9:11 AM.

Details

Summary

Instead of using a MinVersion and MaxVersion field, encode the version
of a builtin using a mask that aligns better with version handling in
OpenCLOptions.h. In addition, this saves a field in the BuiltinTable.

This change allows a finer-grained control over the OpenCL versions in
which a builtin is available: instead of a range, we can now toggle
each version individually.

The fine-grained version control is not yet exposed on the TableGen
definitions side, as changes for OpenCL 3 feature optionality still
need to be defined and will affect how we want to expose these.

Diff Detail

Event Timeline

svenvh created this revision.Apr 14 2021, 9:11 AM
svenvh requested review of this revision.Apr 14 2021, 9:11 AM
azabaznov accepted this revision.Apr 15 2021, 6:47 AM

Great! And thanks for fixing misprint :)

clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
507

nit: Encoded |= clang::encodeOpenCLVersion(VersionIDs[I]);

This revision is now accepted and ready to land.Apr 15 2021, 6:47 AM
svenvh added inline comments.Apr 15 2021, 7:22 AM
clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
507

I wish I could use encodeOpenCLVersion indeed, but the Clang headers are not available in TableGen (see comment on line 493). I couldn't think of a better solution unfortunately, but let me know if you have any suggestions.

azabaznov added inline comments.Apr 15 2021, 11:13 AM
clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
507

Oh, got it! I see no solution except conceptually changing this: allow including clang headers in TableGen util. Seems like it's not possible yet. I think we can go ahead with your solution for now.

This revision was landed with ongoing or failed builds.Apr 19 2021, 2:23 AM
This revision was automatically updated to reflect the committed changes.
srj added a subscriber: srj.Apr 26 2021, 10:15 AM

This change appears to be the injection point for https://bugs.llvm.org/show_bug.cgi?id=50128 -- trying to build clang-tblgen after this change crashes VC2019 if targeting 32-bit Windows (see below). While this is likely an MSVC bug, I presume we still want to support crosscompiling for 32-bit Windows?

[2220/3953] Building CXX object tools\clang\utils\TableGen\CMakeFiles\clang-tblgen.dir\ClangOpenCLBuiltinEmitter.cpp.obj
FAILED: tools/clang/utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOpenCLBuiltinEmitter.cpp.obj 
C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x86\cl.exe  /nologo /TP -DCLANG_ROUND_TRIP_CC1_ARGS=ON -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0 -D_LARGEFILE_SOURCE -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\clang\utils\TableGen -IC:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\utils\TableGen -IC:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\include -Itools\clang\include -Iinclude -IC:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\llvm\include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2  /EHs-c- /GR -UNDEBUG -std:c++14 /showIncludes /Fotools\clang\utils\TableGen\CMakeFiles\clang-tblgen.dir\ClangOpenCLBuiltinEmitter.cpp.obj /Fdtools\clang\utils\TableGen\CMakeFiles\clang-tblgen.dir\ /FS -c C:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\utils\TableGen\ClangOpenCLBuiltinEmitter.cpp
C:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\utils\TableGen\ClangOpenCLBuiltinEmitter.cpp(514) : fatal error C1001: Internal compiler error.
(compiler file 'd:\A01\_work\3\s\src\vctools\Compiler\Utc\src\p2\main.c', line 212)
 To work around this problem, try simplifying or changing the program near the locations listed above.
If possible please provide a repro here: https://developercommunity.visualstudio.com 
Please choose the Technical Support command on the Visual C++ 
 Help menu, or open the Technical Support help file for more information
  cl!RaiseException()+0x69
  cl!RaiseException()+0x69
  cl!CloseTypeServerPDB()+0x22ebf
  cl!CloseTypeServerPDB()+0xedea9

This change appears to be the injection point for https://bugs.llvm.org/show_bug.cgi?id=50128 -- trying to build clang-tblgen after this change crashes VC2019 if targeting 32-bit Windows (see below). While this is likely an MSVC bug, I presume we still want to support crosscompiling for 32-bit Windows?

I am happy to make/accept any adjustments to this patch to fix the particular build. I don't have access to MSVC though, would you be able to help figure out what the problematic construct in my patch was?

srj added a comment.Apr 26 2021, 10:25 AM

From experimentation, it appears that just pulling the MinVersion and MaxVersion expressions from BuiltinNameEmitter::EmitBuiltinTable into separate statements will pacify MSVC, e.g.

auto MinVersion = Overload.first->getValueAsDef("MinVersion")->getValueAsInt("ID");
auto MaxVersion = Overload.first->getValueAsDef("MaxVersion")->getValueAsInt("ID");
OS << "  { " << Overload.second << ", "
   << Overload.first->getValueAsListOfDefs("Signature").size() << ", "
   << (Overload.first->getValueAsBit("IsPure")) << ", "
   << (Overload.first->getValueAsBit("IsConst")) << ", "
   << (Overload.first->getValueAsBit("IsConv")) << ", "
   << FunctionExtensionIndex[ExtName] << ", "
   << MinVersion 
   << ", "
   << MaxVersion 
   << " },\n";
srj added a comment.Apr 26 2021, 10:27 AM

(This is clearly just a weird bug on MSVC's part; there's nothing about the code here that seems obviously unreasonable or complex. Working around compiler bugs is a thing, alas.)

srj added a comment.Apr 26 2021, 10:52 AM

I am happy to make/accept any adjustments to this patch to fix the particular build. I don't have access to MSVC though, would you be able to help figure out what the problematic construct in my patch was?

See my comment above with minor code shuffling which seems to satisfy the compiler.

Thanks for experimenting! I have pushed 37bc1dc9877f ("[NFC] Workaround MSVC2019 32-bit compiler crash", 2021-04-27).