Skip to content
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

Closed
lattner opened this issue May 1, 2004 · 8 comments
Closed

[X86/win32] Large allocas need incremental stack probing #703

lattner opened this issue May 1, 2004 · 8 comments
Assignees

Comments

@lattner
Copy link
Collaborator

lattner commented May 1, 2004

Bugzilla Link 331
Resolution FIXED
Resolved on Feb 22, 2010 12:44
Version 1.0
OS All
Blocks llvm/llvm-bugzilla-archive#790
CC @asl

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

@lattner
Copy link
Collaborator Author

lattner commented May 1, 2004

assigned to @asl

@lattner
Copy link
Collaborator Author

lattner commented Jun 13, 2006

This patch fixed the static case:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060612/035516.html

Now just dynamic alloca's need to be addressed.

-Chris

@asl
Copy link
Collaborator

asl commented Jun 16, 2006

What does it mean "dynamic alloca"? Where can I catch them? Are there any
suitable example?

@lattner
Copy link
Collaborator Author

lattner commented Jun 16, 2006

I mean code like this:

#include <alloca.h>
void foo(int N) {
bar(alloca(N));
}

or:
void foo(int N) {
int A[N];
bar(A);
}

@asl
Copy link
Collaborator

asl commented Apr 16, 2007

Static fix is not so good actually :( It bet it won't work for
regparm'ed\fastcall functions, when there are incoming arguments in eax.
However, I'm not sure. Will check.

@asl
Copy link
Collaborator

asl commented Apr 16, 2007

Yes, it's mine :)

@asl
Copy link
Collaborator

asl commented Nov 27, 2021

mentioned in issue llvm/llvm-bugzilla-archive#790

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
pysuxing pushed a commit to pysuxing/llvm-project that referenced this issue Jul 17, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
…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>
keryell pushed a commit to keryell/llvm-project that referenced this issue Oct 19, 2024
…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>
This issue was closed.
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

No branches or pull requests

2 participants