[AST] Add a convenient getter from QualType to RecordDecl

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

llvm-svn: 338187

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 ...

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 ...

Revert r332847; it caused us to miscompile certain forms of reference initialization.

llvm-svn: 332886

[CodeGen] Recognize more cases of zero initialization

If a variable has an initializer, codegen tries to build its value. If
the variable is large in size, building its value requires substantial
re

[CodeGen] Recognize more cases of zero initialization

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

llvm-svn: 332847

show more ...

[CodeGen] Use the zero initializer instead of storing an all zero representation.

Summary:
This change avoids the overhead of storing, and later crawling,
an initializer list of all zeros for arrays

[CodeGen] Use the zero initializer instead of storing an all zero representation.

Summary:
This change avoids the overhead of storing, and later crawling,
an initializer list of all zeros for arrays. When LLVM
visits this (llvm/IR/Constants.cpp) ConstantArray::getImpl()
it will scan the list looking for an array of all zero.

We can avoid the store, and short-cut the scan, by detecting
all zeros when clang builds-up the initialization representation.

This was brought to my attention when investigating PR36030


Reviewers: majnemer, rjmccall

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 324776

show more ...

[CodeGen][X86] Fix handling of __fp16 vectors.

This commit fixes a bug in IRGen where it generates completely broken
code for __fp16 vectors on X86. For example when the following code is
compiled:

[CodeGen][X86] Fix handling of __fp16 vectors.

This commit fixes a bug in IRGen where it generates completely broken
code for __fp16 vectors on X86. For example when the following code is
compiled:

half4 hv0, hv1, hv2; // these are vectors of __fp16.

void foo221() {
hv0 = hv1 + hv2;
}

clang generates the following IR, in which two i16 vectors are added:

@hv1 = common global <4 x i16> zeroinitializer, align 8
@hv2 = common global <4 x i16> zeroinitializer, align 8
@hv0 = common global <4 x i16> zeroinitializer, align 8

define void @foo221() {
%0 = load <4 x i16>, <4 x i16>* @hv1, align 8
%1 = load <4 x i16>, <4 x i16>* @hv2, align 8
%add = add <4 x i16> %0, %1
store <4 x i16> %add, <4 x i16>* @hv0, align 8
ret void
}

To fix the bug, this commit uses the code committed in r314056, which
modified clang to promote and truncate __fp16 vectors to and from float
vectors in the AST. It also fixes another IRGen bug where a short value
is assigned to an __fp16 variable without any integer-to-floating-point
conversion, as shown in the following example:

__fp16 a;
short b;

void foo1() {
a = b;
}

@b = common global i16 0, align 2
@a = common global i16 0, align 2

define void @foo1() #0 {
%0 = load i16, i16* @b, align 2
store i16 %0, i16* @a, align 2
ret void
}

rdar://problem/20625184

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

llvm-svn: 320215

show more ...

Convert clang::LangAS to a strongly typed enum

Summary:
Convert clang::LangAS to a strongly typed enum

Currently both clang AST address spaces and target specific address spaces
are represented as

Convert clang::LangAS to a strongly typed enum

Summary:
Convert clang::LangAS to a strongly typed enum

Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.

I found the following errors while writing this patch:

- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.

Other than this the patch should not cause any functional changes.

Reviewers: yaxunl, pcc, bader

Reviewed By: yaxunl, bader

Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits

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

llvm-svn: 315871

show more ...

Further refactoring of the constant emitter. NFC.

llvm-svn: 311065

Extract IRGen's constant-emitter into its own helper class and clean up
the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit

Extract IRGen's constant-emitter into its own helper class and clean up
the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit constant initializers that have
ignorable side-effects, or doing the majority of an initialization
in-place and then patching up the last few things with calls. But for
now this is mostly just a refactoring.

llvm-svn: 310964

show more ...

Suppress all uses of LLVM_END_WITH_NULL. NFC.

Use variadic templates instead of relying on <cstdarg> + sentinel.

This enforces better type checking and makes code more readable.

Differential revis

Suppress all uses of LLVM_END_WITH_NULL. NFC.

Use variadic templates instead of relying on <cstdarg> + sentinel.

This enforces better type checking and makes code more readable.

Differential revision: https://reviews.llvm.org/D32550

llvm-svn: 302572

show more ...

[CodeGen] Use APInt::lshrInPlace instead of APInt::lshr. NFC

llvm-svn: 300658

[CodeGen] Unique constant CompoundLiterals.

Our newly aggressive constant folding logic makes it possible for
CGExprConstant to see the same CompoundLiteralExpr more than once. So,
emitting a new Gl

[CodeGen] Unique constant CompoundLiterals.

Our newly aggressive constant folding logic makes it possible for
CGExprConstant to see the same CompoundLiteralExpr more than once. So,
emitting a new GlobalVariable every time we see a CompoundLiteral is no
longer correct.

We had a similar issue with BlockExprs that was caught while testing
said aggressive folding, so I applied the same style of fix (see D26410)
here. If we find yet another case where this needs to happen, we should
probably refactor this so we don't have a third DenseMap+getter+setter.

As a design note: getAddrOfConstantCompoundLiteralIfEmitted is really
only intended to be called by ConstExprEmitter::EmitLValue. So,
returning a GlobalVariable* instead of a ConstantAddress costs us
effectively nothing, and saves us either a few bytes per entry in our
map or a bit of code duplication.

llvm-svn: 290661

show more ...

Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."

Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171

Reviewers: djasper, Anastasia

Subscribers:

Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."

Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171

Reviewers: djasper, Anastasia

Subscribers: yaxunl, cfe-commits, bader

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

llvm-svn: 290431

show more ...

Re-commit r289252 and r289285, and fix PR31374

llvm-svn: 289787

Revert 289252 (and follow-up 289285), it caused PR31374

llvm-svn: 289713

Replace APFloatBase static fltSemantics data members with getter functions

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirec

Replace APFloatBase static fltSemantics data members with getter functions

At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.

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

llvm-svn: 289647

show more ...

Fix unused variable warnings. NFCI.

llvm-svn: 289285

Add support for non-zero null pointer for C and OpenCL

In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address spac

Add support for non-zero null pointer for C and OpenCL

In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.

Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.

Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.

Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.

This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.

This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.

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

llvm-svn: 289252

show more ...

[c++17] P0135R1: Guaranteed copy elision.

When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly

[c++17] P0135R1: Guaranteed copy elision.

When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.

llvm-svn: 288866

show more ...

[CodeGen] Use StringRef. NFC.

Looks like CurFn's name outlives FunctionName, so we can just pass
StringRefs around rather than going from a StringRef to a std::string
to a const char* to a StringRef

[CodeGen] Use StringRef. NFC.

Looks like CurFn's name outlives FunctionName, so we can just pass
StringRefs around rather than going from a StringRef to a std::string
to a const char* to a StringRef.

llvm-svn: 285873

show more ...

[CodeGen] Fix an assert in EmitNullConstant.

r235815 changed CGRecordLowering::accumulateBases to ignore non-virtual
bases of size 0, which prevented adding those non-virtual bases to
CGRecordLayout

[CodeGen] Fix an assert in EmitNullConstant.

r235815 changed CGRecordLowering::accumulateBases to ignore non-virtual
bases of size 0, which prevented adding those non-virtual bases to
CGRecordLayout's NonVirtualBases. This caused clang to assert when
CGRecordLayout::getNonVirtualBaseLLVMFieldNo was called in
EmitNullConstant. This commit fixes the bug by ignoring zero-sized
non-virtual bases in EmitNullConstant.

rdar://problem/28100139

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

llvm-svn: 281405

show more ...