[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

Differential Revision: https://reviews.llvm.org/D123115

show more ...

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the eleventh batch of tests being updated (there are a
significant number of other tests left to be updated).

show more ...

[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences

For a default visibility external linkage definition, dso_local is set for ELF
-fno-pic/-fpie and COFF and

[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences

For a default visibility external linkage definition, dso_local is set for ELF
-fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar
to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences.

To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition,
which sets dso_local for default visibility external linkage definitions.

To make this flip smooth and enable future (dso_local as definition default),
this patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.

show more ...

Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"

This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e.

Accidentally committed.

[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition

Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to sp

[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition

Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to specify -fsemantic-interposition to get semantic
interposition behavior.

Semantic interposition is currently a best-effort feature. There may
still be some cases where it is not handled well.

Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert

Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73865

show more ...

CodeGen: use non-zero memset when possible for automatic variables

Summary:
Right now automatic variables are either initialized with bzero followed by a few stores, or memcpy'd from a synthesized g

CodeGen: use non-zero memset when possible for automatic variables

Summary:
Right now automatic variables are either initialized with bzero followed by a few stores, or memcpy'd from a synthesized global. We end up encountering a fair amount of code where memcpy of non-zero byte patterns would be better than memcpy from a global because it touches less memory and generates a smaller binary. The optimizer could reason about this, but it's not really worth it when clang already knows.

This code could definitely be more clever but I'm not sure it's worth it. In particular we could track a histogram of bytes seen and figure out (as we do with bzero) if a memset could be followed by a handful of stores. Similarly, we could tune the heuristics for GlobalSize, but using the same as for bzero seems conservatively OK for now.

<rdar://problem/42563091>

Reviewers: dexonsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D49771

llvm-svn: 337887

show more ...

Fix typo causing assert in self-host.

llvm-svn: 337508

When we choose to use zeroinitializer for a trailing portion of an array
constant, don't convert the rest into a packed struct.

If an array constant has a large non-zero portion and a large zero
por

When we choose to use zeroinitializer for a trailing portion of an array
constant, don't convert the rest into a packed struct.

If an array constant has a large non-zero portion and a large zero
portion, we want to emit the first part as an array and the rest as a
zeroinitializer if possible. This fixes a memory usage regression from
r333141 when compiling PHP.

llvm-svn: 337498

show more ...

CodeGen: specify alignment + inbounds for automatic variable initialization

Summary: Automatic variable initialization was generating default-aligned stores (which are deprecated) instead of using t

CodeGen: specify alignment + inbounds for automatic variable initialization

Summary: Automatic variable initialization was generating default-aligned stores (which are deprecated) instead of using the known alignment from the alloca. Further, they didn't specify inbounds.

Subscribers: dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D49209

llvm-svn: 337041

show more ...

Use zeroinitializer for (trailing zero portion of) large array initializers
more reliably.

This re-commits r333044 with a fix for PR37560.

llvm-svn: 333141

Revert r333044 "Use zeroinitializer for (trailing zero portion of) large array initializers"

It caused asserts, see PR37560.

> Use zeroinitializer for (trailing zero portion of) large array initial

Revert r333044 "Use zeroinitializer for (trailing zero portion of) large array initializers"

It caused asserts, see PR37560.

> Use zeroinitializer for (trailing zero portion of) large array initializers
> more reliably.
>
> Clang has two different ways it emits array constants (from InitListExprs and
> from APValues), and both had some ability to emit zeroinitializer, but neither
> was able to catch all cases where we could use zeroinitializer reliably. In
> particular, emitting from an APValue would fail to notice if all the explicit
> array elements happened to be zero. In addition, for large arrays where only an
> initial portion has an explicit initializer, we would emit the complete
> initializer (which could be huge) rather than emitting only the non-zero
> portion. With this change, when the element would have a suffix of more than 8
> zero elements, we emit the array constant as a packed struct of its initial
> portion followed by a zeroinitializer constant for the trailing zero portion.
>
> In passing, I found a bug where SemaInit would sometimes walk the entire array
> when checking an initializer that only covers the first few elements; that's
> fixed here to unblock testing of the rest.
>
> Differential Revision: https://reviews.llvm.org/D47166

llvm-svn: 333067

show more ...

Use zeroinitializer for (trailing zero portion of) large array initializers
more reliably.

Clang has two different ways it emits array constants (from InitListExprs and
from APValues), and both had

Use zeroinitializer for (trailing zero portion of) large array initializers
more reliably.

Clang has two different ways it emits array constants (from InitListExprs and
from APValues), and both had some ability to emit zeroinitializer, but neither
was able to catch all cases where we could use zeroinitializer reliably. In
particular, emitting from an APValue would fail to notice if all the explicit
array elements happened to be zero. In addition, for large arrays where only an
initial portion has an explicit initializer, we would emit the complete
initializer (which could be huge) rather than emitting only the non-zero
portion. With this change, when the element would have a suffix of more than 8
zero elements, we emit the array constant as a packed struct of its initial
portion followed by a zeroinitializer constant for the trailing zero portion.

In passing, I found a bug where SemaInit would sometimes walk the entire array
when checking an initializer that only covers the first few elements; that's
fixed here to unblock testing of the rest.

Differential Revision: https://reviews.llvm.org/D47166

llvm-svn: 333044

show more ...

[CodeGen] Initialize large arrays by copying from a global

Currently, clang compiles explicit initializers for array
elements into series of store instructions. For large arrays of
built-in types th

[CodeGen] Initialize large arrays by copying from a global

Currently, clang compiles explicit initializers for array
elements into series of store instructions. For large arrays of
built-in types this results in bloated output code and
significant amount of time spent on the instruction selection
phase. This patch fixes the issue by initializing such arrays
with global constants that store the binary image of the
initializer.

Differential Revision: https://reviews.llvm.org/D43181

llvm-svn: 325478

show more ...

Fixed processing of GNU extensions to C99 designated initializers
Clang did not handles correctly inner parts of arrays/structures initializers in GNU extensions to C99 designated initializers.

llv

Fixed processing of GNU extensions to C99 designated initializers
Clang did not handles correctly inner parts of arrays/structures initializers in GNU extensions to C99 designated initializers.

llvm-svn: 258668

show more ...

Test case updates for explicit type parameter to the gep operator

llvm-svn: 232187

Update test case to make it easier to automatically port to typeless pointer gep operator changes coming soon

llvm-svn: 232185

PR20473: Don't "deduplicate" string literals with the same value but different
lengths! In passing, simplify string literal deduplication by relying on LLVM
to deduplicate the underlying constant val

PR20473: Don't "deduplicate" string literals with the same value but different
lengths! In passing, simplify string literal deduplication by relying on LLVM
to deduplicate the underlying constant values.

llvm-svn: 214222

show more ...

Rework the bitfield access IR generation to address PR13619 and
generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.

The primar

Rework the bitfield access IR generation to address PR13619 and
generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.

The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.

This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.

I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.

llvm-svn: 169489

show more ...

CodeGen: When emitting stores for an initializer, only emit a GEP if we really need the store.

This avoids emitting many dead GEPs for large zero-initialized arrays.

llvm-svn: 162701

Fix a stupid mistake in r151133. Reported to me by Joerg Sonnenberger.

llvm-svn: 151407

Rename CGT::VerifyFuncTypeComplete to isFuncTypeConvertible since
it is a predicate, not an action. Change the return type to be a bool,
not the incomplete member. Enhace it to detect the recursive

Rename CGT::VerifyFuncTypeComplete to isFuncTypeConvertible since
it is a predicate, not an action. Change the return type to be a bool,
not the incomplete member. Enhace it to detect the recursive compilation
case, allowing us to compile Eli's testcase on llvmdev:

struct T {
struct T (*p)(void);
} t;

into:

%struct.T = type { {}* }

@t = common global %struct.T zeroinitializer, align 8

llvm-svn: 134853

show more ...

implement a tiny amount of codegen support for gnu array range
designators: allowing codegen when the element initializer is a
constant or something else without a side effect. This unblocks
enough

implement a tiny amount of codegen support for gnu array range
designators: allowing codegen when the element initializer is a
constant or something else without a side effect. This unblocks
enough to let process.c in the linux kernel build, PR9257.

llvm-svn: 126056

show more ...

Improve codegen for initializer lists to use memset more aggressively
when an initializer is variable (I handled the constant case in a previous
patch). This has three pieces:

1. Enhance AggValueSl

Improve codegen for initializer lists to use memset more aggressively
when an initializer is variable (I handled the constant case in a previous
patch). This has three pieces:

1. Enhance AggValueSlot to have a 'isZeroed' bit to tell CGExprAgg that
the memory being stored into has previously been memset to zero.
2. Teach CGExprAgg to not emit stores of zero to isZeroed memory.
3. Teach CodeGenFunction::EmitAggExpr to scan initializers to determine
whether they are profitable to emit a memset + inividual stores vs
stores for everything.

The heuristic used is that a global has to be more than 16 bytes and
has to be 3/4 zero to be candidate for this xform. The two testcases
are illustrative of the scenarios this catches. We now codegen test9 into:

call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 400, i32 4, i1 false)
%.array = getelementptr inbounds [100 x i32]* %Arr, i32 0, i32 0
%tmp = load i32* %X.addr, align 4
store i32 %tmp, i32* %.array

and test10 into:

call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 392, i32 8, i1 false)
%tmp = getelementptr inbounds %struct.b* %S, i32 0, i32 0
%tmp1 = getelementptr inbounds %struct.a* %tmp, i32 0, i32 0
%tmp2 = load i32* %X.addr, align 4
store i32 %tmp2, i32* %tmp1, align 4
%tmp5 = getelementptr inbounds %struct.b* %S, i32 0, i32 3
%tmp10 = getelementptr inbounds %struct.a* %tmp5, i32 0, i32 4
%tmp11 = load i32* %X.addr, align 4
store i32 %tmp11, i32* %tmp10, align 4

Previously we produced 99 stores of zero for test9 and also tons for test10.
This xforms should substantially speed up -O0 builds when it kicks in as well
as reducing code size and optimizer heartburn on insane cases. This resolves
PR279.

llvm-svn: 120692

show more ...

Enhance the init generation logic to emit a memset followed by a few stores when
a global is larger than 32 bytes and has fewer than 6 non-zero values in the
initializer. Previously we'd turn someth

Enhance the init generation logic to emit a memset followed by a few stores when
a global is larger than 32 bytes and has fewer than 6 non-zero values in the
initializer. Previously we'd turn something like this:

char test8(int X) {
char str[10000] = "abc";

into a 10K global variable which we then memcpy'd from. Now we generate:

%str = alloca [10000 x i8], align 16
%tmp = getelementptr inbounds [10000 x i8]* %str, i64 0, i64 0
call void @llvm.memset.p0i8.i64(i8* %tmp, i8 0, i64 10000, i32 16, i1 false)
store i8 97, i8* %tmp, align 16
%0 = getelementptr [10000 x i8]* %str, i64 0, i64 1
store i8 98, i8* %0, align 1
%1 = getelementptr [10000 x i8]* %str, i64 0, i64 2
store i8 99, i8* %1, align 2

Which is much smaller in space and also likely faster.

This is part of PR279

llvm-svn: 120645

show more ...

Allow a string literal to initialize a tail array (PR8217), patch
by Pierre Habouzit!

llvm-svn: 116165