-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[X86/win32] Large allocas need incremental stack probing #703
Comments
assigned to @asl |
This patch fixed the static case: Now just dynamic alloca's need to be addressed. -Chris |
What does it mean "dynamic alloca"? Where can I catch them? Are there any |
I mean code like this: #include <alloca.h> or: |
Static fix is not so good actually :( It bet it won't work for |
Yes, it's mine :) |
mentioned in issue llvm/llvm-bugzilla-archive#790 |
…vm#703) Mechanical rewrite to use the corresponding free functions; fixes llvm#702. I used a slightly modified version of the `clang-tidy` check provided in https://discourse.llvm.org/t/psa-deprecating-cast-isa-methods-in-some-classes/70909 to rewrite the C++ source files, regular expressions for the TableGen files, and manual cleanups where needed (e.g. chains like `x.foo().cast<A>().bar().cast<B>()`) I applied the following heuristic to determine which namespace prefix to use: - If the target type is not qualified, and the TU has `using namespace mlir` or the code is inside the `mlir` namespace -> use a plain `isa`/`cast`/... - Exception: Always qualify inside custom types and attributes, because their base classes define the very members we want to get rid of. - Else. i.e. the target type is qualified as `::mlir::` or `mlir::`, use that prefix. The `clang-tidy` check also rewrote `dyn_cast_or_null` to `dyn_cast_if_present`. I think that's useful because the former variant is going to be deprecated as well in the future. I'm using `-Werror=deprecated-declarations` to test the change (see 6b7420a93278ee01d37d95882dec39358378cfb3); this required also changing two occurrences of `StringRef::equals` to `==`. I could also just drop the commit here; maybe we want to enable `-Werror` in general (there aren't too many other warnings left in the codebase). --------- Signed-off-by: Julian Oppermann <julian.oppermann@codeplay.com>
…vm#703) Mechanical rewrite to use the corresponding free functions; fixes llvm#702. I used a slightly modified version of the `clang-tidy` check provided in https://discourse.llvm.org/t/psa-deprecating-cast-isa-methods-in-some-classes/70909 to rewrite the C++ source files, regular expressions for the TableGen files, and manual cleanups where needed (e.g. chains like `x.foo().cast<A>().bar().cast<B>()`) I applied the following heuristic to determine which namespace prefix to use: - If the target type is not qualified, and the TU has `using namespace mlir` or the code is inside the `mlir` namespace -> use a plain `isa`/`cast`/... - Exception: Always qualify inside custom types and attributes, because their base classes define the very members we want to get rid of. - Else. i.e. the target type is qualified as `::mlir::` or `mlir::`, use that prefix. The `clang-tidy` check also rewrote `dyn_cast_or_null` to `dyn_cast_if_present`. I think that's useful because the former variant is going to be deprecated as well in the future. I'm using `-Werror=deprecated-declarations` to test the change (see 6b7420a93278ee01d37d95882dec39358378cfb3); this required also changing two occurrences of `StringRef::equals` to `==`. I could also just drop the commit here; maybe we want to enable `-Werror` in general (there aren't too many other warnings left in the codebase). --------- Signed-off-by: Julian Oppermann <julian.oppermann@codeplay.com>
Extended Description
It looks like windows cannot grow the stack by more than 4K at a time, judging
by some code in the C front-end that LLVM doesn't use:
http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm-gcc/gcc/config/i386/cygwin.asm?rev=1.1.1.1&content-type=text/x-cvsweb-markup
To fix this, we should either support an out-of-line alloca on windows like GCC
does, or inline the relevant code (which is probably a bad idea for something
this large).
-Chris
The text was updated successfully, but these errors were encountered: