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
fp stackifier broken #1384
Comments
assigned to @lattner |
Nick, I was getting something similar until I updated my CFE this morning. Did you Reid. |
No, I rebuilt it right before building LLVM. I try to have a working LLVM before I'll try it now. |
No change. |
Builds and tests okay here. Dunno. |
Reduced testcase: float %foo(float %col.2.0) { compiles to: $ llvm-as < t.ll | llc -mcpu=i386 Note that the fucomip compares two zeros against each other. This is probably fallout from Evan's -Chris |
Fixed. Testcase here: CodeGen/X86/fp-stack-compare.ll -Chris |
* [flang] Fix overallocation by fir-to-llvm-ir pass When converting a fir.alloca of an array to the LLVM dialect, we used to multiply the allocated size by all the constant factors encoded in the array type. This is fine when the array type is converted to the element type for the purposes of the allocation, but if it's converted to an array type, then we might be allocating too much space. For example, for `%2 = fir.alloca !fir.array<8x16x32xf32>, %0, %1` we would allocate %0 * %1 * 8 * 16 * 32 x llvm.array<32 x array<16 * array<8 x f32>>>. We really only need to allocate %0 * %1 such arrays. This patch fixes the issue by taking note of the array type that we're trying to allocate. It tries to match the behaviour of LLVMTypeConverter::convertPointerLike, which returns a pointer to the element type only when the array type doesn't have a constant interior. We consequently only multiply with the constant factors in the array type if the array type doesn't have a constant interior. This has the nice side effect that it gets rid of some redundant multiplications with the constant 1 in some cases. Differential Revision: https://reviews.llvm.org/D116926 * Update Fir/alloc.fir It just contained a redundant multiplication with 1.
Extended Description
Latest CVS (since about a week ago) broke a dozen tests in my nightly. Testcase
attached.
The text was updated successfully, but these errors were encountered: