Instead of having -Os/-Oz add OptimizeForSize/MinSize first, and later
having OptimizeNone remove them again, just don't add them in the
first place if the function already has OptimizeNone.

Note th

Instead of having -Os/-Oz add OptimizeForSize/MinSize first, and later
having OptimizeNone remove them again, just don't add them in the
first place if the function already has OptimizeNone.

Note that MinSize can still appear due to attributes on different
declarations; a future patch will address that.

llvm-svn: 224047

show more ...

IR: Update clang for Metadata/Value split in r223802

Match LLVM API changes from r223802.

llvm-svn: 223803

InstrProf: Use LLVM's -instrprof pass for profiling

The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.

ll

InstrProf: Use LLVM's -instrprof pass for profiling

The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.

llvm-svn: 223683

show more ...

Fix invalid calling convention used for libcalls on ARM.
ARM ABI specifies that all the libcalls use soft FP ABI
(even hard FP binaries). These days clang emits _mulsc3 / _muldc3
calls with default

Fix invalid calling convention used for libcalls on ARM.
ARM ABI specifies that all the libcalls use soft FP ABI
(even hard FP binaries). These days clang emits _mulsc3 / _muldc3
calls with default (C) calling convention which would be translated
into AAPCS_VFP LLVM calling and thus the result of complex
multiplication will be bogus.

Introduce a way for a target to specify explicitly calling
convention for libcalls. Right now this is temporary correctness
fix. Ultimately, we'll end with intrinsic for complex
multiplication and all calling convention decisions for libcalls
will be put into backend.

llvm-svn: 223123

show more ...

Use nullptr to silence -Wsentinel when self-hosting on Windows

Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an inte

Use nullptr to silence -Wsentinel when self-hosting on Windows

Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an integer
literal zero and fires off a warning. Only CodeGen currently knows that
it promotes integer literal zeroes in this context to pointer size on
Windows. I didn't want to teach -Wsentinel about that compatibility
hack. Therefore, I'm migrating to C++11 nullptr.

llvm-svn: 223079

show more ...

Add missing 'break's, found by inspection. No functionality change; the
fallthrough happened to do the right thing in both cases.

llvm-svn: 223064

Correctly remove OptimizeForSize from functions marked OptimizeNone.
This allows using __attribute__((optnone)) and the -Os/-Oz options.
Fixes PR21604.

llvm-svn: 222683

Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept.

llvm-svn: 222335

clang-format a recent commit I made

llvm-svn: 222317

Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue.

llvm-svn: 222306

Add PIC-level support to Clang.

Summary:
This distinguishes between -fpic and -fPIC now, with the additions in LLVM for
PIC level support.

Test Plan: No regressions

Reviewers: echristo, rafael

Re

Add PIC-level support to Clang.

Summary:
This distinguishes between -fpic and -fPIC now, with the additions in LLVM for
PIC level support.

Test Plan: No regressions

Reviewers: echristo, rafael

Reviewed By: rafael

Subscribers: rnk, emaste, llvm-commits

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

llvm-svn: 222227

show more ...

[Objective-C++ IRGen] do not generate .cxx_construct
for class that contains trivially-constructible struct ivar.
rdar://18950072

llvm-svn: 221823

Revert "IR: MDNode => Value: Update for LLVM API change in r221375"

This reverts commit r221376.

The API change was reverted in r221711.

llvm-svn: 221712

[OPENMP] Codegen for threadprivate variables
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Ori

[OPENMP] Codegen for threadprivate variables
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002

llvm-svn: 221663

show more ...

Introduce a SanitizerKind enum to LangOptions.

Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled san

Introduce a SanitizerKind enum to LangOptions.

Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.

No functionality change.

llvm-svn: 221558

show more ...

IR: MDNode => Value: Update for LLVM API change in r221375

llvm-svn: 221376

Don't dllimport inline functions when targeting MinGW (PR21366)

It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with

Don't dllimport inline functions when targeting MinGW (PR21366)

It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.

To fix this, make Clang never dllimport inline functions when targeting
MinGW.

llvm-svn: 221154

show more ...

CodeGen: Virtual dtor thunks shouldn't have this marked as 'returned'

The ARM ABI virtual destructor thunks cannot be marked as 'returned'
because they return undef.

llvm-svn: 221042

[ASan] Improve blacklisting of global variables.

This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, o

[ASan] Improve blacklisting of global variables.

This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:

1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.

2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.

3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().

After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).

llvm-svn: 220097

show more ...

SanitizerBlacklist: blacklist functions by their source location.

This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and tur

SanitizerBlacklist: blacklist functions by their source location.

This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:

1) Function is explicitly blacklisted by its mangled name.
This part is not changed.

2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.

After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.

After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.

I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).

llvm-svn: 219997

show more ...

MS Compat: mark globals emitted in read-only sections const

They cannot be written to, so marking them const makes sense and may improve
optimisation.

As a side-effect, SectionInfos has to be moved

MS Compat: mark globals emitted in read-only sections const

They cannot be written to, so marking them const makes sense and may improve
optimisation.

As a side-effect, SectionInfos has to be moved from Sema to ASTContext.

It also fixes this problem, that occurs when compiling ATL:

warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes

The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.

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

llvm-svn: 219960

show more ...

CodeGen: Don't drop thread_local when emitting __thread aliases

CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.

Even if the definition was already emitt

CodeGen: Don't drop thread_local when emitting __thread aliases

CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.

Even if the definition was already emitted, it would never mark the
alias as thread_local.

This fixes PR21288.

llvm-svn: 219859

show more ...

Move SanitizerBlacklist object from CodeGenModule to ASTContext.

Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the

Move SanitizerBlacklist object from CodeGenModule to ASTContext.

Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the blacklist earlier.

llvm-svn: 219857

show more ...

Move -fsanitize-blacklist to LangOpts from CodeGenOpts. NFC.

After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it w

Move -fsanitize-blacklist to LangOpts from CodeGenOpts. NFC.

After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it will actually affect ABI / class layout).

llvm-svn: 219842

show more ...

Fix for bug http://llvm.org/PR17427.
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.

Fix for bug http://llvm.org/PR17427.
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365

llvm-svn: 219393

show more ...