History log of /llvm-project-15.0.7/clang/lib/CodeGen/CodeGenModule.cpp (Results 751 – 775 of 1864)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# c2d2b425 15-Oct-2015 Benjamin Kramer <[email protected]>

[CodeGen] Remove dead code. NFC.

llvm-svn: 250418


# aec6b2c2 08-Oct-2015 Akira Hatanaka <[email protected]>

[CodeGen] [CodeGen] Attach function attributes to functions created in
CGBlocks.cpp.

This commit fixes a bug in clang's code-gen where it creates the
following functions but doesn't attach function

[CodeGen] [CodeGen] Attach function attributes to functions created in
CGBlocks.cpp.

This commit fixes a bug in clang's code-gen where it creates the
following functions but doesn't attach function attributes to them:

__copy_helper_block_
__destroy_helper_block_
__Block_byref_object_copy_
__Block_byref_object_dispose_

rdar://problem/20828324

Differential Revision: http://reviews.llvm.org/D13525

llvm-svn: 249735

show more ...


# 200500d6 08-Oct-2015 Akira Hatanaka <[email protected]>

[CodeGen] Check if the Decl pointer passed is null, and if so, return
early.

This is needed in a patch I plan to commit later, in which a null Decl
pointer is passed to SetLLVMFunctionAttributesForD

[CodeGen] Check if the Decl pointer passed is null, and if so, return
early.

This is needed in a patch I plan to commit later, in which a null Decl
pointer is passed to SetLLVMFunctionAttributesForDefinition.

Relevant discussion is in http://reviews.llvm.org/D13525.

llvm-svn: 249722

show more ...


# 3f02150d 08-Oct-2015 David Majnemer <[email protected]>

[MSVC Compat] Enable ABI impacting non-conforming behavior independently of -fms-compatibility

No ABI for C++ currently makes it possible to implement the standard
100% perfectly. We wrongly hid so

[MSVC Compat] Enable ABI impacting non-conforming behavior independently of -fms-compatibility

No ABI for C++ currently makes it possible to implement the standard
100% perfectly. We wrongly hid some of our compatible behavior behind
-fms-compatibility instead of tying it to the compiler ABI.

llvm-svn: 249656

show more ...


# ed1fe5d0 03-Oct-2015 Yaron Keren <[email protected]>

Replace double-negated !SourceLocation.isInvalid() with SourceLocation.isValid().

llvm-svn: 249228


# c005cc06 27-Sep-2015 Craig Topper <[email protected]>

Use llvm::makeArrayRef. NFC.

llvm-svn: 248678


# 510d7c71 21-Sep-2015 Akira Hatanaka <[email protected]>

Remove attributes minsize and optsize, which conflict with optnone.

This commit fixes an assert that is triggered when optnone is being
added to an IR function that is already marked with minsize an

Remove attributes minsize and optsize, which conflict with optnone.

This commit fixes an assert that is triggered when optnone is being
added to an IR function that is already marked with minsize and optsize.

rdar://problem/22723716

Differential Revision: http://reviews.llvm.org/D13004

llvm-svn: 248191

show more ...


# b8327868 17-Sep-2015 Piotr Padlewski <[email protected]>

Using MD_invariant_group

http://reviews.llvm.org/D12927

llvm-svn: 247933


# 10aa7703 16-Sep-2015 Reid Kleckner <[email protected]>

[WinEH] Pass the catch adjectives to catchpad directly

This avoids building a fake LLVM IR global variable just to ferry an i32
down into LLVM codegen. It also puts a nail in the coffin of using MS

[WinEH] Pass the catch adjectives to catchpad directly

This avoids building a fake LLVM IR global variable just to ferry an i32
down into LLVM codegen. It also puts a nail in the coffin of using MS
ABI C++ EH with landingpads, since now we'll assert in the lpad code
when flags are present.

llvm-svn: 247843

show more ...


# 4b1ac72c 15-Sep-2015 Piotr Padlewski <[email protected]>

Decorating vptr load & stores with !invariant.group

Adding !invariant.group to vptr load/stores for devirtualization purposes.
For more goto:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227

Decorating vptr load & stores with !invariant.group

Adding !invariant.group to vptr load/stores for devirtualization purposes.
For more goto:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

http://reviews.llvm.org/D12026

llvm-svn: 247725

show more ...


# 9d0ecf27 15-Sep-2015 Piotr Padlewski <[email protected]>

Added llvm.module flag for strict vtable pointers

It is dangerous to do LTO on code with strict-vtable-pointers, because
one module has invariant.group.barriers, and the other one not.

In the futur

Added llvm.module flag for strict vtable pointers

It is dangerous to do LTO on code with strict-vtable-pointers, because
one module has invariant.group.barriers, and the other one not.

In the future I want to just strip all invariant.group metadata from
vptrs loads/stores and get rid of invariant.group.barrier calls.

http://reviews.llvm.org/D12580

llvm-svn: 247724

show more ...


# 6b2a61d3 14-Sep-2015 Evgeniy Stepanov <[email protected]>

Revert "Always_inline codegen rewrite" and 2 follow-ups.

Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions."
Revert "[CodeGen] Remove wrapper-free always_inline functions

Revert "Always_inline codegen rewrite" and 2 follow-ups.

Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions."
Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs"
Revert "Always_inline codegen rewrite."

Reason for revert: PR24793.

llvm-svn: 247620

show more ...


# 2a791d7d 14-Sep-2015 David Blaikie <[email protected]>

[opaque pointer type] Fix a few uses of PointerType::getElementType in favor of uses of types already available elsewhere

These are a few cleanups I happened to have from trying to go in a
different

[opaque pointer type] Fix a few uses of PointerType::getElementType in favor of uses of types already available elsewhere

These are a few cleanups I happened to have from trying to go in a
different direction recently, so just flushing them out while I have
them.

llvm-svn: 247593

show more ...


# aff29d30 14-Sep-2015 David Blaikie <[email protected]>

Revert "[opaque pointer type] update for LLVM API change"

This was the wrong direction to take anyway (because ultimately the
GlobalValue needed the pointee type again and /it/ used
PointerType::get

Revert "[opaque pointer type] update for LLVM API change"

This was the wrong direction to take anyway (because ultimately the
GlobalValue needed the pointee type again and /it/ used
PointerType::getElementType eventually anyway)... let's go a different way.

This reverts commit r236161.

llvm-svn: 247586

show more ...


# 67cb9740 12-Sep-2015 David Majnemer <[email protected]>

[CodeGen] Remove wrapper-free always_inline functions from COMDATs

always_inline functions without a wrapper don't need to be in a COMDAT.

llvm-svn: 247500


# 93db40a1 12-Sep-2015 Evgeniy Stepanov <[email protected]>

Always_inline codegen rewrite.

Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally always

Always_inline codegen rewrite.

Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.

Libc++ relies on the compiler never emitting such undefined reference.

With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.

The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).

This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.

This patch is based on ideas by Chandler Carruth and Richard Smith.

llvm-svn: 247494

show more ...


# 67037ee2 11-Sep-2015 Evgeniy Stepanov <[email protected]>

Revert "Specify target triple in alwaysinline tests."
Revert "Always_inline codegen rewrite."

Breaks gdb & lldb tests.
Breaks on Fedora 22 x86_64.

llvm-svn: 247491


# 072e8350 11-Sep-2015 Evgeniy Stepanov <[email protected]>

Always_inline codegen rewrite.

Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally always

Always_inline codegen rewrite.

Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.

Libc++ relies on the compiler never emitting such undefined reference.

With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.

The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).

This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.

This patch is based on ideas by Chandler Carruth and Richard Smith.

llvm-svn: 247465

show more ...


# da1851ca 10-Sep-2015 Artem Belevich <[email protected]>

[CUDA] Allow trivial constructors as initializer for __shared__ variables.

Differential Revision: http://reviews.llvm.org/D12739

llvm-svn: 247307


# 2c7f7e31 10-Sep-2015 Peter Collingbourne <[email protected]>

CFI: Introduce -fsanitize=cfi-icall flag.

This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bit

CFI: Introduce -fsanitize=cfi-icall flag.

This flag causes the compiler to emit bit set entries for functions as well
as runtime bitset checks at indirect call sites. Depends on the new function
bitset mechanism.

Differential Revision: http://reviews.llvm.org/D11857

llvm-svn: 247238

show more ...


# 25a80bf9 08-Sep-2015 Peter Collingbourne <[email protected]>

CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

This function can be used to create a metadata identifier for a specific
type. No functionality change, but this will be used by D1

CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.

This function can be used to create a metadata identifier for a specific
type. No functionality change, but this will be used by D11857 and D12026.

Differential Revision: http://reviews.llvm.org/D12038

llvm-svn: 247098

show more ...


# 7f416cc4 08-Sep-2015 John McCall <[email protected]>

Compute and preserve alignment more faithfully in IR-generation.

Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. C

Compute and preserve alignment more faithfully in IR-generation.

Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

llvm-svn: 246985

show more ...


# 0e2b975e 04-Sep-2015 Hal Finkel <[email protected]>

Don't crash on a self-alias declaration

We were crashing in CodeGen given input like this:

int self_alias(void) __attribute__((weak, alias("self_alias")));

such a self-alias is invalid, but inst

Don't crash on a self-alias declaration

We were crashing in CodeGen given input like this:

int self_alias(void) __attribute__((weak, alias("self_alias")));

such a self-alias is invalid, but instead of diagnosing the situation, we'd
proceed to produce IR for both the function declaration and the alias. Because
we already had a function named 'self_alias', the alias could not be named the
same thing, and so LLVM would pick a different name ('self_alias1' for example)
for that value. When we later called CodeGenModule::checkAliases, we'd look up
the IR value corresponding to the alias name, find the function declaration
instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent
this is simply to avoid creating the wrongly-named alias value in the first
place and issue the diagnostic there (instead of in checkAliases). We detect a
related cycle case in CodeGenModule::EmitAliasDefinition already, so this just
adds a second such check.

Even though the other test cases for this 'alias definition is part of a cycle'
diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression
test for this case. This is because I can't add this check to
test/Sema/attr-alias-elf.c without disturbing the other test cases in that
file. In order to avoid construction of the bad IR values, this diagnostic
is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant
declaration is not added to the Aliases vector). The other cycle checks are
done within the CodeGenModule::checkAliases function based on the Aliases
vector, called from CodeGenModule::Release. However, if there have been errors
earlier, HandleTranslationUnit does not call Release, and so checkAliases is
never called, and so none of the other diagnostics would be produced.

Fixes PR23509.

llvm-svn: 246882

show more ...


# c285307e 03-Sep-2015 Dan Gohman <[email protected]>

[WebAssembly] Initial WebAssembly support in clang

This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
fina

[WebAssembly] Initial WebAssembly support in clang

This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.

Differential Revision: http://reviews.llvm.org/D12002

llvm-svn: 246814

show more ...


# cab5858e 31-Aug-2015 Andrey Bokhanko <[email protected]>

PR17829: Proper diagnostic of mangled names conflicts

Proper diagnostic and resolution of mangled names conflicts between C++ methods
and C functions. This patch implements support for functions/met

PR17829: Proper diagnostic of mangled names conflicts

Proper diagnostic and resolution of mangled names conflicts between C++ methods
and C functions. This patch implements support for functions/methods only;
support for variables is coming separately.

Differential Revision: http://reviews.llvm.org/D11297

llvm-svn: 246438

show more ...


1...<<31323334353637383940>>...75