llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.28k stars 11.68k forks source link

lto + try-catch affect sp point in x86 #96637

Open SihangZhu opened 3 months ago

SihangZhu commented 3 months ago

follow is example code

#include <stdio.h>
void f (int i)
{
  throw i;
}

int main ()
{
  void *sp1 = __builtin_alloca (0);

  try
    {
      f (0);
    }
  catch (int)
    {
    }

  void *sp2 = __builtin_alloca (0);
  if(sp1 != sp2) {printf("sp1 != sp2\n");}
  else {printf("sp1 == sp2\n");}

  return (sp1 != sp2);
}

compiling commands: clang++ -flto demo.cpp -o demo.exe -std=c++11

the result of this demo is "sp1 == sp2" compiled with gcc, while clang is "sp1 != sp2" Is there some wrong in llvm's lto

dtcxzyw commented 3 months ago

Why does __builtin_alloca(0) always returns the value of stack pointer?

I don't see any docs saying about that. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005falloca https://clang.llvm.org/docs/LanguageExtensions.html#builtin-alloca

SihangZhu commented 3 months ago

Why does __builtin_alloca(0) always returns the value of stack pointer?

I don't see any docs saying about that. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005falloca https://clang.llvm.org/docs/LanguageExtensions.html#builtin-alloca

Thank you for taking the time to answer. I found that x86 rearranges the addresses of variables on the stack, which is what causes the results to be inconsistent with gcc. But as you've also explained, builtin_alloca doesn't have this limitation. This optimization is also reasonable.