unique_ptrify createDriverOptTable

llvm-svn: 291919

Add a cc1 option to force disabling lifetime-markers emission from clang

Summary: This intended as a debugging/development flag only.

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

llvm-sv

Add a cc1 option to force disabling lifetime-markers emission from clang

Summary: This intended as a debugging/development flag only.

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

llvm-svn: 291300

show more ...

Reapply "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and CodeCompleteConsumer"

Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was exp

Reapply "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and CodeCompleteConsumer"

Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.

Thanks Aleksey!

This reapplies r291184, reverted in r291249.

llvm-svn: 291270

show more ...

Revert "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and CodeCompleteConsumer"

Caused a memory leak reported by asan. Reverting while I investigate.

This reverts commit r291184.

Revert "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and CodeCompleteConsumer"

Caused a memory leak reported by asan. Reverting while I investigate.

This reverts commit r291184.

llvm-svn: 291249

show more ...

IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and CodeCompleteConsumer

llvm-svn: 291184

Use shared_ptr instead of IntrusiveRefCntPtr for ModuleFileExtension

The intrusiveness wasn't needed here, so this simplifies/clarifies the
ownership model.

llvm-svn: 291150

Add -f[no-]strict-return flag that can be used to avoid undefined behaviour
in non-void functions that fall off at the end without returning a value when
compiling C++.

Clang uses the new compiler f

Add -f[no-]strict-return flag that can be used to avoid undefined behaviour
in non-void functions that fall off at the end without returning a value when
compiling C++.

Clang uses the new compiler flag to determine when it should treat control flow
paths that fall off the end of a non-void function as unreachable. If
-fno-strict-return is on, the code generator emits the ureachable and trap
IR only when the function returns either a record type with a non-trivial
destructor or another non-trivially copyable type.

The primary goal of this flag is to avoid treating falling off the end of a
non-void function as undefined behaviour. The burden of undefined behaviour
is placed on the caller instead: if the caller ignores the returned value then
the undefined behaviour is avoided. This kind of behaviour is useful in
several cases, e.g. when compiling C code in C++ mode.

rdar://13102603

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

llvm-svn: 290960

show more ...

[c++17] Implement P0522R0 as written. This allows a template template argument
to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (whe

[c++17] Implement P0522R0 as written. This allows a template template argument
to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.

This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.

The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.

llvm-svn: 290792

show more ...

[PM] Introduce options to enable the (still experimental) new pass
manager, and a code path to use it.

The option is actually a top-level option but does contain
'experimental' in the name. This is

[PM] Introduce options to enable the (still experimental) new pass
manager, and a code path to use it.

The option is actually a top-level option but does contain
'experimental' in the name. This is the compromise suggested by Richard
in discussions. We expect this option will be around long enough and
have enough users towards the end that it merits not being relegated to
CC1, but it still needs to be clear that this option will go away at
some point.

The backend code is a fresh codepath dedicated to handling the flow with
the new pass manager. This was also Richard's suggested code structuring
to essentially leave a clean path for development rather than carrying
complexity or idiosyncracies of how we do things just to share code with
the parts of this in common with the legacy pass manager. And it turns
out, not much is really in common even though we use the legacy pass
manager for codegen at this point.

I've switched a couple of tests to run with the new pass manager, and
they appear to work. There are still plenty of bugs that need squashing
(just with basic experiments I've found two already!) but they aren't in
this code, and the whole point is to expose the necessary hooks to start
experimenting with the pass manager in more realistic scenarios.

That said, I want to *strongly caution* anyone itching to play with
this: it is still *very shaky*. Several large components have not yet
been shaken down. For example I have bugs in both the always inliner and
inliner that I have already spotted and will be fixing independently.

Still, this is a fun milestone. =D

One thing not in this patch (but that might be very reasonable to add)
is some level of support for raw textual pass pipelines such as what
Sean had a patch for some time ago. I'm mostly interested in the more
traditional flow of getting the IR out of Clang and then running it
through opt, but I can see other use cases so someone may want to add
it.

And of course, *many* features are not yet supported!
- O1 is currently more like O2
- None of the sanitizers are wired up
- ObjC ARC optimizer isn't wired up
- ...

So plenty of stuff still lef to do!

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

llvm-svn: 290450

show more ...

Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.

These were really, really tangled together:
- We used the noinline LLVM attribute for -fno

Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.

These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.

Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.

I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.

One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.

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

llvm-svn: 290398

show more ...

Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.

Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Cla

Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.

Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.

There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.

This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.

This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.

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

llvm-svn: 290392

show more ...

Revert another accidental bit

llvm-svn: 290125

Undo accidental comit

llvm-svn: 290121

[PS4] Undo dialect tweak for Objective-C.

In r267772, we had set the PS4's default dialect for both C and
Objective-C to gnu99. Make that change only for C; we don't really
support Objective-C/C++

[PS4] Undo dialect tweak for Objective-C.

In r267772, we had set the PS4's default dialect for both C and
Objective-C to gnu99. Make that change only for C; we don't really
support Objective-C/C++ so there's no point fiddling the dialect.

llvm-svn: 289625

show more ...

Simplify parseShowColorsArgs logic, NFC.

llvm-svn: 289328

Revert r285664, cxx-abi-dev chose to go in a different direction for the ABI here.

llvm-svn: 288304

[Preprocessor] Support for '-dI' flag

Re-introduce r285411.

Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.

This change aims to add

[Preprocessor] Support for '-dI' flag

Re-introduce r285411.

Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.

This change aims to add this option, pass it through to the preprocessor via
the options class, and when inclusions occur we output some information (+ test
cases).

Patch by Steve O'Brien!

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

llvm-svn: 287275

show more ...

Add a new optimization option -Og

Summary:
Just like gcc, we should have the -Og option as more and more software are using it:
https://llvm.org/bugs/show_bug.cgi?id=20765

Reviewers: echristo, dbe

Add a new optimization option -Og

Summary:
Just like gcc, we should have the -Og option as more and more software are using it:
https://llvm.org/bugs/show_bug.cgi?id=20765

Reviewers: echristo, dberlin, dblaikie, keith.walker.arm, rengolin

Subscribers: aprantl, friss, mehdi_amini, RKSimon, probinson, majnemer, cfe-commits

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

llvm-svn: 286602

show more ...

Fix Clang-tidy readability-redundant-string-cstr warnings

Reviewers: aaron.ballman, mehdi_amini, dblaikie

Subscribers: cfe-commits

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

llvm-svn:

Fix Clang-tidy readability-redundant-string-cstr warnings

Reviewers: aaron.ballman, mehdi_amini, dblaikie

Subscribers: cfe-commits

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

llvm-svn: 285799

show more ...

[OpenCL] Override supported OpenCL extensions with -cl-ext option

Summary:
This patch adds a command line option '-cl-ext' to control a set of
supported OpenCL extensions. Option accepts a comma-sep

[OpenCL] Override supported OpenCL extensions with -cl-ext option

Summary:
This patch adds a command line option '-cl-ext' to control a set of
supported OpenCL extensions. Option accepts a comma-separated list
of extensions prefixed with '+' or '-'.

It can be used together with a target triple to override support for some
extensions:

// spir target supports all extensions, but we want to disable fp64
clang -cc1 -triple spir-unknown-unknown -cl-ext=-cl_khr_fp64

Special 'all' extension allows to enable or disable all possible
extensions:

// only fp64 will be supported
clang -cc1 -triple spir-unknown-unknown -cl-ext=-all,+cl_khr_fp64

Patch by asavonic (Andrew Savonichev).

Reviewers: joey, yaxunl

Subscribers: yaxunl, bader, Anastasia, cfe-commits

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

llvm-svn: 285700

show more ...

Implement ABI proposal for throwing noexcept function pointers, per discussion
on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a
cc1-only -m flag, pending discussion of h

Implement ABI proposal for throwing noexcept function pointers, per discussion
on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a
cc1-only -m flag, pending discussion of how best to deal with language changes
that require use of new symbols from the ABI library.

llvm-svn: 285664

show more ...

Revert "[Preprocessor] Support for '-dI' flag"

This reverts r285411. Tests failing on
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/141

llvm-svn: 285416

[Preprocessor] Support for '-dI' flag

Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.

This change aims to add this option, pass it th

[Preprocessor] Support for '-dI' flag

Implement the -dI as supported by GCC: Output ‘#include’ directives in addition
to the result of preprocessing.

This change aims to add this option, pass it through to the preprocessor via
the options class, and when inclusions occur we output some information (+ test
cases).

Patch by Steve O'Brien!

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

llvm-svn: 285411

show more ...

Do not print include_next/pragma once warnings when input is a header.

r276653 suppressed the pragma once warning when generating a PCH file.
This patch extends that to any main file for which clang

Do not print include_next/pragma once warnings when input is a header.

r276653 suppressed the pragma once warning when generating a PCH file.
This patch extends that to any main file for which clang is told (with
the -x option) that it's a header file. It will also suppress the
warning "#include_next in primary source file".

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

llvm-svn: 285295

show more ...

Switch SmallSetVector to use DenseSet when it overflows its inline space.

Summary:
SetVector already used DenseSet, but SmallSetVector used std::set. This
leads to surprising performance difference

Switch SmallSetVector to use DenseSet when it overflows its inline space.

Summary:
SetVector already used DenseSet, but SmallSetVector used std::set. This
leads to surprising performance differences. Moreover, it means that
the set of key types accepted by SetVector and SmallSetVector are
quite different!

In order to make this change, we had to convert some callsites that used
SmallSetVector<std::string, N> to use SmallSetVector<CachedHashString, N>
instead.

Reviewers: timshen

Subscribers: llvm-commits

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

llvm-svn: 284887

show more ...