UNREACHABLE executed at llvm/lib/CodeGen/ValueTypes.cpp

Alcpz commented 4 months ago

Describe the bug

clang++ -DGGML_SCHED_MAX_COPIES=4 -DGGML_USE_LLAMAFILE -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -I/sources/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -Wmissing-declarations -Wmissing-noreturn -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -Wmissing-prototypes -Wextra-semi -march=native -MD -MT CMakeFiles/llama.dir/unicode.cpp.o -MF CMakeFiles/llama.dir/unicode.cpp.o.d -o CMakeFiles/llama.dir/unicode.cpp.o -c /sources/llama.cpp/unicode.cpp
Unknown type!
UNREACHABLE executed at /sources/llvm/lib/CodeGen/ValueTypes.cpp:592!
PLEASE submit a bug report to https://github.com/intel/llvm/issues and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: /dpcpp-nightly/2024-06-02/bin/clang++ -DGGML_SCHED_MAX_COPIES=4 -DGGML_USE_LLAMAFILE -D_GNU_SOURCE -D_XOPEN_SOURCE=600 -I/sources/llama.cpp/. -O3 -DNDEBUG -std=gnu++11 -Wmissing-declarations -Wmissing-noreturn -Wall -Wextra -Wpedantic -Wcast-qual -Wno-unused-function -Wunreachable-code-break -Wunreachable-code-return -Wmissing-prototypes -Wextra-semi -march=native -MD -MT CMakeFiles/llama.dir/unicode.cpp.o -MF CMakeFiles/llama.dir/unicode.cpp.o.d -o CMakeFiles/llama.dir/unicode.cpp.o -c /sources/llama.cpp/unicode.cpp
1.  <eof> parser at end of file
2.  Optimizer
 #0 0x0000565413ec320f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/dpcpp-nightly/2024-06-02/bin/clang+++0x2b7120f)
 #1 0x0000565413ec0d4c llvm::sys::CleanupOnSignal(unsigned long) (/dpcpp-nightly/2024-06-02/bin/clang+++0x2b6ed4c)
 #2 0x0000565413e0d648 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x00007fbb30ad0520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #4 0x00007fbb30b249fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #5 0x00007fbb30b249fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #6 0x00007fbb30b249fc pthread_kill ./nptl/pthread_kill.c:89:10
 #7 0x00007fbb30ad0476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #8 0x00007fbb30ab67f3 abort ./stdlib/abort.c:81:7
 #9 0x0000565413e18c8e (/dpcpp-nightly/2024-06-02/bin/clang+++0x2ac6c8e)
#10 0x00005654134ae226 (/dpcpp-nightly/2024-06-02/bin/clang+++0x215c226)
#11 0x00005654122e5a06 llvm::X86TTIImpl::getInterleavedMemoryOpCostAVX512(unsigned int, llvm::FixedVectorType*, unsigned int, llvm::ArrayRef<unsigned int>, llvm::Align, unsigned int, llvm::TargetTransformInfo::TargetCostKind, bool, bool) (/dpcpp-nightly/2024-06-02/bin/clang+++0xf93a06)
#12 0x00005654122e6f46 llvm::X86TTIImpl::getInterleavedMemoryOpCost(unsigned int, llvm::Type*, unsigned int, llvm::ArrayRef<unsigned int>, llvm::Align, unsigned int, llvm::TargetTransformInfo::TargetCostKind, bool, bool) (/dpcpp-nightly/2024-06-02/bin/clang+++0xf94f46)
#13 0x0000565412fdb2a6 llvm::TargetTransformInfo::getInterleavedMemoryOpCost(unsigned int, llvm::Type*, unsigned int, llvm::ArrayRef<unsigned int>, llvm::Align, unsigned int, llvm::TargetTransformInfo::TargetCostKind, bool, bool) const (/dpcpp-nightly/2024-06-02/bin/clang+++0x1c892a6)
#14 0x00005654157fe671 llvm::LoopVectorizationCostModel::getInterleaveGroupCost(llvm::Instruction*, llvm::ElementCount) (/dpcpp-nightly/2024-06-02/bin/clang+++0x44ac671)
#15 0x0000565415816691 llvm::LoopVectorizationCostModel::setCostBasedWideningDecision(llvm::ElementCount) (/dpcpp-nightly/2024-06-02/bin/clang+++0x44c4691)
#16 0x0000565415837052 llvm::LoopVectorizationPlanner::plan(llvm::ElementCount, unsigned int) (/dpcpp-nightly/2024-06-02/bin/clang+++0x44e5052)
#17 0x000056541583a35f llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/dpcpp-nightly/2024-06-02/bin/clang+++0x44e835f)
#18 0x000056541583d64d llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AssumptionCache&, llvm::LoopAccessInfoManager&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) (/dpcpp-nightly/2024-06-02/bin/clang+++0x44eb64d)
#19 0x000056541583e8a0 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x44ec8a0)
#20 0x000056541538a396 llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x4038396)
#21 0x000056541387c04d llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x252a04d)
#22 0x000056541230cff6 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0xfbaff6)
#23 0x000056541387a95d llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x252895d)
#24 0x000056541230e776 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0xfbc776)
#25 0x00005654138787ed llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x25267ed)
#26 0x00005654141836f3 (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>&, std::unique_ptr<llvm::ToolOutputFile, std::default_delete<llvm::ToolOutputFile>>&, clang::BackendConsumer*) BackendUtil.cpp:0:0
#27 0x000056541418739d (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) BackendUtil.cpp:0:0
#28 0x0000565414187a76 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/dpcpp-nightly/2024-06-02/bin/clang+++0x2e35a76)
#29 0x00005654148158bd clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x34c38bd)
#30 0x00005654166c737d clang::ParseAST(clang::Sema&, bool, bool) (/dpcpp-nightly/2024-06-02/bin/clang+++0x537537d)
#31 0x0000565414817709 clang::CodeGenAction::ExecuteAction() (/dpcpp-nightly/2024-06-02/bin/clang+++0x34c5709)
#32 0x0000565414af8979 clang::FrontendAction::Execute() (/dpcpp-nightly/2024-06-02/bin/clang+++0x37a6979)
#33 0x0000565414a7a1be clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x37281be)
#34 0x0000565414be6e56 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/dpcpp-nightly/2024-06-02/bin/clang+++0x3894e56)
#35 0x00005654122964fc cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/dpcpp-nightly/2024-06-02/bin/clang+++0xf444fc)
#36 0x000056541228f74a ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#37 0x000056541487f12d void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#38 0x0000565413e0db50 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/dpcpp-nightly/2024-06-02/bin/clang+++0x2abbb50)
#39 0x000056541487f85f clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const (.part.0) Job.cpp:0:0
#40 0x0000565414821c39 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/dpcpp-nightly/2024-06-02/bin/clang+++0x34cfc39)
#41 0x000056541482272e clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/dpcpp-nightly/2024-06-02/bin/clang+++0x34d072e)
#42 0x000056541482d875 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/dpcpp-nightly/2024-06-02/bin/clang+++0x34db875)
#43 0x0000565412293acb clang_main(int, char**, llvm::ToolContext const&) (/dpcpp-nightly/2024-06-02/bin/clang+++0xf41acb)
#44 0x00005654121b827b main (/dpcpp-nightly/2024-06-02/bin/clang+++0xe6627b)
#45 0x00007fbb30ab7d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#46 0x00007fbb30ab7e40 call_init ./csu/../csu/libc-start.c:128:20
#47 0x00007fbb30ab7e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#48 0x000056541228f1de _start (/dpcpp-nightly/2024-06-02/bin/clang+++0xf3d1de)
clang++: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 19.0.0git
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /dpcpp-nightly/2024-06-02/bin
Build config: +assertions
clang++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/unicode-83b7f7.cpp
clang++: note: diagnostic msg: /tmp/unicode-83b7f7.sh
clang++: note: diagnostic msg:

Both unicode-83b7f7 files have been attatched below: unicode.tar.gz

To reproduce

git clone -b codeplay/sycl-main https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -S . -G Ninja \
        -DCMAKE_CXX_COMPILER=$(which clang++) \
        -DCMAKE_C_COMPILER=$(which clang)
ninja -C build llama-bench

~I've been unable to find a smaller reproducer. I will try to narrow it down further, since llama.cpp codebase is quite big.~

Minor reproducer below:

#include <future>
#include <vector>

// To make it fail:
// clang++ -O2 -march=native -o test ./test.cpp
// Removing either O2 (or O3) or march does not trigger the issue

// clang++ -O2 -o test ./test.cpp

int main() {
  // Works
  std::future<bool> b;
  b = std::async(std::launch::async, [] { return true; });
  b.wait();

  // Doesn't work
  std::vector<std::future<bool>> foo;
  foo.emplace_back(std::async(std::launch::async, [] { return true; }));
  foo[0].wait();

  return 0;
}

The issue arises with the use of std::future inside a std::vector. To trigger it, both -O2 (or -O3) and-march=native` flags have to be used.

Environment

OS Linux Ubuntu 22.04, Linux 5.15.0-107-generic # 117-Ubuntu SMP Fri Apr 26 12:26:49 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Target Device (Issue is CPU codegen related, not SYCL backend related) Intel(R) Xeon(R) Gold 6326 CPU @ 2.90GHz Also reproduced in an Intel(R) Xeon(R) Platinum 8268 CPU @ 2.90GHz
clang++ version: Tried multiple versions, running a bisect points the first bad commit to d6d1948c156810af89bf67ca637623c15a3bd098: #13894
sycl-ls --verbose (Not applicable, bug triggers outside of the SYCL backend)

Additional context

I was able to successfully build the application using clang directly, both at the merged commit (llvm/llvm-project@781b13538e55a42b2d02bb4d21779f15ff8a640c), and a more recent one (llvm/llvm-project@3602efa78ddc16f82c338358748b3a13b3859e24).

I am unable to replicate the issue on a different system with a 12th Gen Intel(R) Core(TM) i9-12900K CPU.

Edit: Added another CPU where the issue can be reproduced Edit: Added reproducer.

Alcpz commented 4 months ago

Added a reproducer. I am not sure what additional info could be provided, but I am happy to find more info if needed.

dm-vodopyanov commented 4 months ago

Similar issue with shorter reproducer: https://github.com/intel/llvm/issues/14288

pawan-nirpal-031 commented 4 months ago

Hi I'm triaging the issue, I see that with my local latest release build of icx, the build is successful.

[6/21] Building C object CMakeFiles/ggml.dir/ggml.c.o
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1938:5: warning: implicit conversion increases floating-point precision: 'float' to 'ggml_float' (aka 'double') [-Wdouble-promotion]
    GGML_F16_VEC_REDUCE(sumf, sum);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1143:37: note: expanded from macro 'GGML_F16_VEC_REDUCE'
#define GGML_F16_VEC_REDUCE         GGML_F32Cx16_REDUCE
                                    ^
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1132:11: note: expanded from macro 'GGML_F32Cx16_REDUCE'
    res = _mm512_reduce_add_ps(x[0]);                             \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1986:9: warning: implicit conversion increases floating-point precision: 'float' to 'ggml_float' (aka 'double') [-Wdouble-promotion]
        GGML_F16_VEC_REDUCE(sumf[k], sum[k]);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1143:37: note: expanded from macro 'GGML_F16_VEC_REDUCE'
#define GGML_F16_VEC_REDUCE         GGML_F32Cx16_REDUCE
                                    ^
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1132:11: note: expanded from macro 'GGML_F32Cx16_REDUCE'
    res = _mm512_reduce_add_ps(x[0]);                             \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
[8/21] Building CXX object CMakeFiles/llama.dir/llama.cpp.o
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11783:38: warning: using floating point absolute value function 'fabs' when argument is of integer type [-Wabsolute-value]
                                f = -fabs(lctx.kv_self.cells[i].pos - pos);
                                     ^
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11783:38: note: use function 'std::abs' instead
                                f = -fabs(lctx.kv_self.cells[i].pos - pos);
                                     ^~~~
                                     std::abs
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11816:42: warning: using floating point absolute value function 'fabs' when argument is of integer type [-Wabsolute-value]
                                    f = -fabs(batch.pos[i] - batch.pos[j]);
                                         ^
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11816:42: note: use function 'std::abs' instead
                                    f = -fabs(batch.pos[i] - batch.pos[j]);
                                         ^~~~
                                         std::abs
2 warnings generated.
[10/21] Generating build details from Git
-- Found Git: /nfs/igk/disks/igk_icl_rdrive_cmode/lref1/ics/itools/unx/bin/git (found version "2.39.1") 
[21/21] Linking CXX executable bin/llama-bench

pawan-nirpal-031 commented 4 months ago

Hi I'm triaging the issue, I see that with my local latest release build of icx, the build is successful.

[6/21] Building C object CMakeFiles/ggml.dir/ggml.c.o
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1938:5: warning: implicit conversion increases floating-point precision: 'float' to 'ggml_float' (aka 'double') [-Wdouble-promotion]
    GGML_F16_VEC_REDUCE(sumf, sum);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1143:37: note: expanded from macro 'GGML_F16_VEC_REDUCE'
#define GGML_F16_VEC_REDUCE         GGML_F32Cx16_REDUCE
                                    ^
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1132:11: note: expanded from macro 'GGML_F32Cx16_REDUCE'
    res = _mm512_reduce_add_ps(x[0]);                             \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1986:9: warning: implicit conversion increases floating-point precision: 'float' to 'ggml_float' (aka 'double') [-Wdouble-promotion]
        GGML_F16_VEC_REDUCE(sumf[k], sum[k]);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1143:37: note: expanded from macro 'GGML_F16_VEC_REDUCE'
#define GGML_F16_VEC_REDUCE         GGML_F32Cx16_REDUCE
                                    ^
/localdisk2/pawanani/triage/llama.cpp/ggml.c:1132:11: note: expanded from macro 'GGML_F32Cx16_REDUCE'
    res = _mm512_reduce_add_ps(x[0]);                             \
        ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
[8/21] Building CXX object CMakeFiles/llama.dir/llama.cpp.o
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11783:38: warning: using floating point absolute value function 'fabs' when argument is of integer type [-Wabsolute-value]
                                f = -fabs(lctx.kv_self.cells[i].pos - pos);
                                     ^
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11783:38: note: use function 'std::abs' instead
                                f = -fabs(lctx.kv_self.cells[i].pos - pos);
                                     ^~~~
                                     std::abs
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11816:42: warning: using floating point absolute value function 'fabs' when argument is of integer type [-Wabsolute-value]
                                    f = -fabs(batch.pos[i] - batch.pos[j]);
                                         ^
/localdisk2/pawanani/triage/llama.cpp/llama.cpp:11816:42: note: use function 'std::abs' instead
                                    f = -fabs(batch.pos[i] - batch.pos[j]);
                                         ^~~~
                                         std::abs
2 warnings generated.
[10/21] Generating build details from Git
-- Found Git: /nfs/igk/disks/igk_icl_rdrive_cmode/lref1/ics/itools/unx/bin/git (found version "2.39.1") 
[21/21] Linking CXX executable bin/llama-bench

Even with a debug build no crash is seen. Machine used for testing : Model name: Intel(R) Xeon(R) Platinum 8490H

pawan-nirpal-031 commented 4 months ago

I couldn't get the exact same setup I managed to get a machine with following config

RedHat9.0 | 96 cores | cascadelake | Xeon(R) Platinum 8260 CPU

But, I do not see the crash on smaller test case that is given here. Nevertheless It could be highly specific to the config mentioned.

dm-vodopyanov commented 4 months ago

I see that with my local latest release build of icx, the build is successful.

@pawan-nirpal-031 Crash is in syclos, not in the closed-source compiler. It is possible that the closed-source compiler is not yet updated with the changes from syclos.

pawan-nirpal-031 commented 4 months ago

I'm able to reproduce the crash, I am suspecting something broke during pulldown.

Alcpz commented 3 months ago

@pawan-nirpal-031 I've bisected the issue down to the d6d1948c156810af89bf67ca637623c15a3bd098 commit (https://github.com/intel/llvm/pull/13894). The issue is not present in the sycl parent of the merge nor the llvm-project parent commit.

pawan-nirpal-031 commented 3 months ago

Yes @Alcpz I am able to reproduce the crash at that point in sycl-web, but I'm not sure how to bisect this aggregate commit.

pawan-nirpal-031 commented 3 months ago

Root  cause : This commit by upstream expects users of MVT::getVT to pass on a boolean 
HandleUnknown, for the simple test case via gdb, coming from the following function call from /llvm/lib/Target/X86/X86TargetTransformInfo.cpp:6260

  MVT VT = MVT::getVectorVT(MVT::getVT(VecTy->getScalarType()), VF);

expects some boolean to be passed on into getVT, and further in this call if this boolean is false then it runs into 

MVT MVT::getVT(Type *Ty, bool HandleUnknown){
  assert(Ty != nullptr && "Invalid type");
  switch (Ty->getTypeID()) {
  default:
    if (HandleUnknown) return MVT(MVT::Other);
    llvm_unreachable("Unknown type!");

Hence the crash, we must either keep ( -  case Type::PointerTyID:   return MVT(MVT::iPTR); ) or pass a boolean as true, to avoid running into the crash. 

commit 7c937df05b7c636287e6058bb2e700618ff57c2f
Author: Jessica Clarke <jrtc27@jrtc27.com>
Date:   Wed May 22 23:56:43 2024 +0100

    [CodeGen] Forbid passing a PointerType to MVT::getVT and EVT::getEVT (#92671)

    There is the expectation throughout CodeGen that, for types representing
    "real" values, the MVT or EVT is self-contained. However, MVT::iPTR is
    challenging, because it has no address space, and even if it did, there
    often is no DataLayout immediately accessible to determine what actually
    is the underlying type.

    Historically it was documented as being TableGen-only, but that was lost
    in 631bfdbee5b45eda9f99dff6a716d63c5698e4bd's conversion to using the
    generated defines. Let's preserve that intent by not allowing it to
    originate through accidental calls to get(E)VT with a PointerType. If
    you need to support that, be sure to use something like TargetLowering's
    getValueType, which takes a DataLayout and can map pointers to their
    concrete MVTs. Whilst here, reintroduce documentation about these value
    types being TableGen-only.

pawan-nirpal-031 commented 3 months ago

Also refer to : [[CodeGen][X86] Use TargetLowering for TypeInfo of PointerTy (#93469) · llvm/llvm-project@3082258 (github.com)|https://github.com/llvm/llvm-project/commit/3082258d3a29664a66fcd35c104a40b8cf9d6cba] and Blaming llvm-project/llvm/lib/Target/X86/X86TargetTransformInfo.cpp at main · llvm/llvm-project (github.com)

pawan-nirpal-031 commented 3 months ago

I have a patch for this, just tested it on short test case.

diff --git a/llvm/lib/Target/X86/X86TargetTransformInfo.cpp b/llvm/lib/Target/X86/X86TargetTransformInfo.cpp
index ac66144aeaae..78252b245511 100644
--- a/llvm/lib/Target/X86/X86TargetTransformInfo.cpp
+++ b/llvm/lib/Target/X86/X86TargetTransformInfo.cpp
@@ -6257,7 +6257,7 @@ InstructionCost X86TTIImpl::getInterleavedMemoryOpCostAVX512(
                                 AddressSpace, CostKind);

   unsigned VF = VecTy->getNumElements() / Factor;
-  MVT VT = MVT::getVectorVT(MVT::getVT(VecTy->getScalarType()), VF);
+  MVT VT = MVT::getVectorVT(TLI->getSimpleValueType(DL, VecTy->getScalarType()), VF);

   InstructionCost MaskCost;
   if (UseMaskedMemOp) {

pawan-nirpal-031 commented 3 months ago

The issue came up due to, the fix for this came after the pulldown mentioned by @Alcpz so we're just going to wait for the next pulldown to happen and this should be fixed automatically. Please refer to this commit that should be the incoming fix : https://github.com/llvm/llvm-project/commit/3082258d3a29664a66fcd35c104a40b8cf9d6cba

dm-vodopyanov commented 3 months ago

@pawan-nirpal-031, the commit https://github.com/llvm/llvm-project/commit/3082258d3a29664a66fcd35c104a40b8cf9d6cba was merged to llorg on May 29. We now have the latest draft of llorg-intel/llvm pulldown, and it starts from June 24. Not sure that your suggestion will work here. Can you please investigate more?

dm-vodopyanov commented 3 months ago

@pawan-nirpal-031 in future, please link PRs with GH issues. If this ticket is resolved, please close it.

PR: https://github.com/intel/llvm/pull/14439

pawan-nirpal-031 commented 3 months ago

Sure @dm-vodopyanov thanks for informing.

dm-vodopyanov commented 3 months ago

If this ticket is resolved, please close it.

@pawan-nirpal-031 friendly ping. What is the status of the ticket considering the PR mentioned above was merged?

Alcpz commented 3 months ago

I was able to compile the source code that was giving me issues with today's nightly build (2024-07-08). I think this is solved. @pawan-nirpal-031 can you confirm everything is fine on your side as well?

pawan-nirpal-031 commented 3 months ago

Hi @dm-vodopyanov @Alcpz note that the issue has been merged all clear from my side as well, and the ticket has been closed. Thanks for your constant support. Cheers.

intel / llvm