History log of /llvm-project/clang/lib/CodeGen/CodeGenModule.cpp (Results 1051 – 1075 of 2157)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# b8327868 17-Sep-2015 Piotr Padlewski <prazek@google.com>

Using MD_invariant_group

http://reviews.llvm.org/D12927

llvm-svn: 247933


# 10aa7703 16-Sep-2015 Reid Kleckner <rnk@google.com>

[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 <prazek@google.com>

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 <prazek@google.com>

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 <eugeni.stepanov@gmail.com>

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 <dblaikie@gmail.com>

[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 <dblaikie@gmail.com>

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 <david.majnemer@gmail.com>

[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 <eugeni.stepanov@gmail.com>

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 <eugeni.stepanov@gmail.com>

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 <eugeni.stepanov@gmail.com>

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 <tra@google.com>

[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 <peter@pcc.me.uk>

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 <peter@pcc.me.uk>

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 <rjmccall@apple.com>

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 <hfinkel@anl.gov>

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 <dan433584@gmail.com>

[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 <andreybokhanko@gmail.com>

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


# 6eaa8323 28-Aug-2015 Hans Wennborg <hans@hanshq.net>

Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593)

This patch does two things:

1) Don't error about dllimport/export on thread-local static local vari

Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593)

This patch does two things:

1) Don't error about dllimport/export on thread-local static local variables.
We put those attributes on static locals in dllimport/export functions
implicitly in case the function gets inlined. Now, for TLS variables this
is a problem because we can't import such variables, but it's a benign
problem becase:

2) Make sure we never inline a dllimport function TLS static locals. In fact,
never inline a dllimport function that references a non-imported function
or variable (because these are not defined in the importing library). This
seems to match MSVC's behaviour.

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

llvm-svn: 246338

show more ...


Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4
# 284ebe23 22-Aug-2015 Jingyue Wu <jingyue@google.com>

[CUDA] Change initializer for CUDA device code based on CUDA documentation.

Summary:
According to CUDA documentation, global variables declared with __device__,
__constant__ can be initialized from

[CUDA] Change initializer for CUDA device code based on CUDA documentation.

Summary:
According to CUDA documentation, global variables declared with __device__,
__constant__ can be initialized from host code, so mark them as
externally initialized. Because __shared__ variables cannot have an
initialization as part of their declaration and since the value maybe kept
across different kernel invocation, the value of __shared__ is effectively
undefined instead of zero initialized.

Wrongly using zero initializer may cause illegitimate optimization, e.g.
removing unused __constant__ variable because it's not updated in the device
code and the value is initialized with zero.

Test Plan: test/CodeGenCUDA/address-spaces.cu

Patch by Xuetian Weng

Reviewers: jholewinski, eliben, tra, jingyue

Subscribers: llvm-commits

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

llvm-svn: 245786

show more ...


Revision tags: llvmorg-3.7.0-rc3
# c52efa7d 19-Aug-2015 Richard Smith <richard-llvm@metafoo.co.uk>

[modules] Don't eagerly deserialize so many ImportDecls. CodeGen basically ignores ImportDecls imported from modules, so only eagerly deserialize the ones from a PCH / preamble.

llvm-svn: 245406


# 2dcef9e0 13-Aug-2015 David Majnemer <david.majnemer@gmail.com>

Avoid iteration invalidation issues around MaterializedTemporaryExpr

We risk iterator invalidation issues if we use a DenseMap to hold the
backing storage for an APValue. Instead, BumpPtrAllocate t

Avoid iteration invalidation issues around MaterializedTemporaryExpr

We risk iterator invalidation issues if we use a DenseMap to hold the
backing storage for an APValue. Instead, BumpPtrAllocate them and
use APValue * as our DenseMap value.

Also, don't assume that MaterializedGlobalTemporaryMap won't regrow
between when we initially perform a lookup and later on when we actually
try to insert into it.

This fixes PR24289.

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

llvm-svn: 244989

show more ...


Revision tags: studio-1.4
# 556b21aa 13-Aug-2015 Yaron Keren <yaron.keren@gmail.com>

Remove and forbid raw_svector_ostream::flush() calls.
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as th

Remove and forbid raw_svector_ostream::flush() calls.
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.

Thanks to David Blaikie for reviewing.

llvm-svn: 244928

show more ...


# 02d5d86b 06-Aug-2015 Eric Christopher <echristo@gmail.com>

Rename the non-coding style conformant functions in namespace Builtins
to match the rest of their brethren and reformat the bits that need it.

llvm-svn: 244186


# 124955aa 05-Aug-2015 Reid Kleckner <reid@kleckner.net>

Add -gcodeview and -gdwarf to control which type Clang emits

Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and

Add -gcodeview and -gdwarf to control which type Clang emits

Summary:
By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can
force emission of one or both by passing -gcodeview and -gdwarf to
either driver.

Reviewers: dblaikie, hans

Subscribers: cfe-commits

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

llvm-svn: 244097

show more ...


1...<<41424344454647484950>>...87