If a variable has an initializer, codegen tries to build its value. If
the variable is large in size, building its value requires substantial
resources. It causes strange behavior from user viewpoint: compilation
of huge zero initialized arrays like:
char data_1[2147483648u] = { 0 };
consumes enormous amount of time and memory.
With this change codegen tries to determine if variable initializer is
equivalent to zero initializer. In this case variable value is not
constructed.
This change fixes PR18978.
Differential Revision: https://reviews.llvm.org/D46241
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332847 91177308-0d34-0410-b5e6-96231b3b80d8
Given something like:
void *v = (void *)100;
We need to synthesize a ptrtoint operation from 100. During constant
emission, we choose i64 as the type for our constant because it
guaranteed not to drop any bits from our CharUnits representation of the
value. However, this is suboptimal for 32-bit targets: LLVM passes like
GlobalOpt will get confused by these sorts of casts resulting in
pessimization.
Instead, make sure the ptrtoint operand has a pointer-sized integer
type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273020 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r220169 which reverted r220153. However, it also
contains additional changes:
- We may need to add padding *after* we've packed the struct. This
occurs when the aligned next field offset is greater than the new
field's offset. When this occurs, we make the struct packed.
*However*, once packed the next field offset might be less than the
new feild's offset. It is in this case that we might further pad the
struct.
- We would pad structs which were perfectly sized! This behavior is
immensely old. This behavior came from blindly subtracting
NextFieldOffsetInChars from RecordSize. This doesn't take into
account the fact that the struct might have a greater overall
alignment than the last field.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220175 91177308-0d34-0410-b5e6-96231b3b80d8
This commit caused two tests in LNT to regress. I'm able to reproduce on
any platform and will send reproduction steps to the original commit
log. This should restore the LNT bots that have been failing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220169 91177308-0d34-0410-b5e6-96231b3b80d8
Before, ConstStructBuilder::AppendBytes would check packed constraints
prior to padding being added before the field's offset. However, adding
this padding might force our struct to be packed. Because we wouldn't
check *after* adding padding, ConstStructBuilder would be in an
inconsistent state leading to a crash.
This fixes PR21300.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220153 91177308-0d34-0410-b5e6-96231b3b80d8
stuff like this:
typedef struct {
int x, y, z;
} foo_t;
foo_t g;
into:
%"struct.<anonymous>" = type { i32, i32, i32 }
we now get:
%struct.foo_t = type { i32, i32, i32 }
This doesn't change the behavior of the compiler, but makes the IR much easier to read.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134969 91177308-0d34-0410-b5e6-96231b3b80d8
ConvertType on InitListExprs as they are being converted. This is
needed for a forthcoming patch, and improves the IR generated anyway
(see additional type names in testcases).
This patch also converts a bunch of std::vector's in CGObjCMac to use
C arrays. There are a ton more that should be converted as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133413 91177308-0d34-0410-b5e6-96231b3b80d8
static const char foo[] = "foo";
static const char *bar = "bar";
the global created to hold "bar" will have it, but foo will not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123192 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
of a floating point number. This add regular expressions to account
for this. Patch by John Thompson.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83581 91177308-0d34-0410-b5e6-96231b3b80d8
- PR3463, PR3398, <rdar://problem/6553401> crash on relocatable
symbol addresses as constants in static locals.
- There are many more scenarious we could handle (like arithmetic on
such an int) but this is the main use case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65074 91177308-0d34-0410-b5e6-96231b3b80d8
- Merged into single ComplexEvaluator, these share too much logic to
be worth splitting for float/int (IMHO). Will split on request.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63248 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith