Commit Graph

44 Commits

Author SHA1 Message Date
Chandler Carruth fcd33149b4 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
2016-12-23 01:24:49 +00:00
Chandler Carruth 93786da2cb 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
2016-12-23 00:23:01 +00:00
Piotr Padlewski d679d7e924 Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Edit:
Fixed version because of PR24479 and other bug caused in chrome.
After this patch got reverted because of ScalarEvolution bug (D12719)
Merged after John McCall big patch (Added Address).

http://reviews.llvm.org/D11859
http://reviews.llvm.org/D12865

llvm-svn: 247646
2015-09-15 00:37:06 +00:00
Piotr Padlewski 4bed31b9bf Revert "Generating assumption loads of vptr after ctor call (fixed)"
It seems that there is small bug, and we can't generate assume loads
when some virtual functions have internal visibiliy
This reverts commit 982bb7d966947812d216489b3c519c9825cacbf2.

llvm-svn: 247332
2015-09-10 20:18:30 +00:00
Piotr Padlewski 255652e828 Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Edit:
Fixed version because of PR24479.
After this patch got reverted because of ScalarEvolution bug (D12719)
Merged after John McCall big patch (Added Address).

http://reviews.llvm.org/D11859

llvm-svn: 247199
2015-09-09 22:20:28 +00:00
Steven Wu 5528da76ef Revert r246214 and r246213
These two commits causes llvm LTO bootstrap to hang in ScalarEvolution.

llvm-svn: 246282
2015-08-28 07:14:10 +00:00
Piotr Padlewski 81461a4350 Assume loads fix #2
There was linker problem, and it turns out that it is not always safe
to refer to vtable. If the vtable is used, then we can refer to it
without any problem, but because we don't know when it will be used or
not, we can only check if vtable is external or it is safe to to emit it
speculativly (when class it doesn't have any inline virtual functions).
It should be fixed in the future.

http://reviews.llvm.org/D12385

llvm-svn: 246214
2015-08-27 21:35:41 +00:00
Piotr Padlewski 525f746710 Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Edit:
Fixed version because of PR24479.

http://reviews.llvm.org/D11859

llvm-svn: 246213
2015-08-27 21:35:37 +00:00
Piotr Padlewski fa0e11efdd Revert "Generating assumption loads of vptr after ctor call (fixed)"
Reverting because of 245721

This reverts commit 552658e2b60543c928030b09cc9b5dfcb40c3f28.

llvm-svn: 245727
2015-08-21 19:49:41 +00:00
Piotr Padlewski 910a059e42 Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Edit:
Fixed version because of PR24479.

http://reviews.llvm.org/D11859

llvm-svn: 245721
2015-08-21 18:28:00 +00:00
Justin Bogner 3c32c83daa Revert "Generating assumption loads of vptr after ctor call (fixed)"
Bootstrap bots were failing:

http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/6382/
http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/2969

This reverts r245264.

llvm-svn: 245267
2015-08-18 05:40:20 +00:00
Piotr Padlewski bc7497abbb Generating assumption loads of vptr after ctor call (fixed)
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Edit:
Fixed version because of PR24479.

http://reviews.llvm.org/D11859

llvm-svn: 245264
2015-08-18 03:52:00 +00:00
Hans Wennborg 386e442d1d Revert r245257 "Generating assumption loads of vptr after ctor call"
It caused PR24479

llvm-svn: 245260
2015-08-18 00:17:58 +00:00
Piotr Padlewski a3f6f9477b Generating assumption loads of vptr after ctor call
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.

For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

http://reviews.llvm.org/D11859

llvm-svn: 245257
2015-08-17 23:33:49 +00:00
Rafael Espindola 6bedf4a707 Set comdat when an available_externally thunk is converted to linkonce_odr.
Fixes pr24130.

llvm-svn: 242293
2015-07-15 14:48:06 +00:00
Peter Collingbourne 8fabc1b47d CodeGen: Do not give local-linkage functions externally available linkage, even temporarily.
When an internal-linkage thunk is code gen'd, CodeGenVTables::emitThunk
will first be called with ForVTable=true (which incorrectly set the
thunk's linkage to available_externally under the Itanium ABI) and later
with ForVTable=false (which reset it to internal). Because we will always
see a call with ForVTable=false, this incorrect linkage never ended up in
the final IR. However, the temporary presence of this linkage caused us
to give such functions a comdat as a result of code introduced in r241102.
To avoid this, check that the thunk is externally visible before giving it
available_externally linkage.

llvm-svn: 241136
2015-07-01 02:10:26 +00:00
NAKAMURA Takumi c7da6da58e Revert r236879, "Do not emit thunks with available_externally linkage in comdats"
It broke pecoff, at least i686-cygwin.

llvm-svn: 236937
2015-05-09 21:10:07 +00:00
Derek Schuff 2312bd3811 Do not emit thunks with available_externally linkage in comdats
Functions with available_externally linkage will not be emitted to object
files (they will just be undefined symbols), so it does not make sense to
put them in comdats.

Creates a second overload of maybeSetTrivialComdat that uses the GlobalObject
instead of the Decl, and uses that in several places that had the faulty
logic.

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

llvm-svn: 236879
2015-05-08 16:47:21 +00:00
David Blaikie a953f2825b Update Clang tests to handle explicitly typed load changes in LLVM.
llvm-svn: 230795
2015-02-27 21:19:58 +00:00
David Blaikie 218b783192 Update Clang tests to handle explicitly typed gep changes in LLVM.
llvm-svn: 230783
2015-02-27 19:18:17 +00:00
Rafael Espindola e5df59ff78 Emit DeferredDeclsToEmit in a DFS order.
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.

* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.

llvm-svn: 226751
2015-01-22 00:24:57 +00:00
John McCall 8f80a61914 Remove the -fhidden-weak-vtables -cc1 option. It was dead,
gross, and increasingly replaced through other mechanisms.

llvm-svn: 201011
2014-02-08 00:41:16 +00:00
Benjamin Kramer 065c61b646 CodeGen: Don't emit linkage on thunks that aren't emitted because they're vararg.
This can happen when we're trying to emit a thunk with available_externally
linkage with optimization enabled but bail because it doesn't make sense
for vararg functions.

PR18098.

llvm-svn: 196658
2013-12-07 16:12:52 +00:00
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Tim Northover 19ae1175ae Fix FileCheck --check-prefix lines.
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.

Patch by Ron Ofir.

llvm-svn: 188174
2013-08-12 12:51:05 +00:00
Bill Wendling 2386bb130c Reapply r176133 with testcase fixes.
llvm-svn: 176145
2013-02-27 00:06:04 +00:00
Anna Zaks 0f424b029b Revert "Add more attributes from the command line to functions."
This reverts commit 176009.

The commit is a likely cause of several buildbot failures.

llvm-svn: 176044
2013-02-25 19:51:03 +00:00
Bill Wendling 87869db5f5 Add more attributes from the command line to functions.
This is an ongoing process. Any command line option which a back-end cares about
should be added here.

llvm-svn: 176009
2013-02-25 07:15:16 +00:00
Bill Wendling c33fc4c004 Modify the tests to use attribute group references instead of listing the
function attributes.

llvm-svn: 175606
2013-02-20 07:22:19 +00:00
Rafael Espindola 86792438dc Call CGM.SetLLVMFunctionAttributesForDefinition on thunks so that they get
attributes like uwtable. Without uwtable a stack unwinder would be unable
to go past the thunks.

llvm-svn: 164411
2012-09-21 20:39:32 +00:00
Eli Friedman 00755e9554 Fix thunk emission for covariant virtual functions in cases which require
both a virtual and a non-virtual offset. PR13832.

llvm-svn: 163866
2012-09-14 01:45:09 +00:00
John McCall eed64c77d2 Complain about attempts to use 'protected' visibility on targets
like Darwin that don't support it.  We should also complain about
invalid -fvisibility=protected, but that information doesn't seem
to exist at the most appropriate time, so I've left a FIXME behind.

llvm-svn: 149186
2012-01-29 01:20:30 +00:00
Eli Friedman 49a94b1c7c Add an implementation of thunks for varargs methods. The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos. A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 .
llvm-svn: 130993
2011-05-06 17:27:27 +00:00
John McCall 8377967543 Warn about code that uses variables and functions with internal linkage
without defining them.  This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition.  I'll revisit later.

Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake.  Doing so produces an invalid module
if the variable is not ultimately defined.

Also, fix several places in the test suite where we were using internal
functions without definitions.

llvm-svn: 126016
2011-02-19 02:53:41 +00:00
John McCall 478382521e When re-using a vtable slot for the nearest overridden method, just because
there's no return adjustment from the overridden to the overrider doesn't
mean there isn't a return adjustment from the overrider to the final
overrider.  This matters if we're emitting a virtual this-adjustment thunk
because the overrider virtually inherits from the class providing the
nearest overridden method.  Do the appropriate return adjustment in this case.

Fixes PR7611.

llvm-svn: 118466
2010-11-09 01:18:05 +00:00
John McCall b3732bb3b7 Just disable the hidden-visibility optimization for now by hiding it behind
a -cc1 option.  The Darwin linker complains about mixed visibility when linking
gcc-built objects with clang-built objects, and the optimization isn't really
that valuable.  Platforms with less ornery linkers can feel free to enable this.

llvm-svn: 110979
2010-08-12 23:36:15 +00:00
John McCall c8bd9c277b Extend the visibility-hidden optimization to linkonce_odr thunks for
functions with in-line definitions, since such thunks will be emitted at any
use of the function.

Completes the feature work for rdar://problem/7523229.

llvm-svn: 110285
2010-08-04 23:46:35 +00:00
John McCall 6a7f9f5c8f Don't try to emit the vtable for a class just because we're emitting a
virtual function from it.

Fixes PR7241.

llvm-svn: 105345
2010-06-02 21:22:02 +00:00
John McCall 23f6626262 Correctly pass aggregates by reference when emitting thunks.
llvm-svn: 104778
2010-05-26 22:34:26 +00:00
Douglas Gregor c5871f07f0 When generating the call arguments in a thunk to call the thunkee, do
not make copies non-POD arguments or arguments passed by reference:
just copy the pointers directly. This eliminates another source of the
dreaded memcpy-of-non-PODs. Fixes PR7188.

llvm-svn: 104327
2010-05-21 17:55:12 +00:00
Douglas Gregor aa2ac80eaa When creating a this-adjustment thunk where the return value is of C++
class type (that uses a return slot), pass the return slot to the
callee directly rather than allocating new storage and trying to copy
the object. This appears to have been the cause of the remaining two
Boost.Interprocess failures.

llvm-svn: 104215
2010-05-20 05:54:35 +00:00
Douglas Gregor 88d292ccb8 Rework when and how vtables are emitted, by tracking where vtables are
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions. 

The new scheme:
  - For every use of a vtable, Sema calls MarkVTableUsed() to indicate
  the use. For example, this occurs when calling a virtual member
  function of the class, defining a constructor of that class type,
  dynamic_cast'ing from that type to a derived class, casting
  to/through a virtual base class, etc.
  - For every definition of a vtable, Sema calls MarkVTableUsed() to
  indicate the definition. This happens at the end of the translation
  unit for classes whose key function has been defined (so we can
  delay computation of the key function; see PR6564), and will also
  occur with explicit template instantiation definitions.
 - For every vtable defined/used, we mark all of the virtual member
 functions of that vtable as defined/used, unless we know that the key
 function is in another translation unit. This instantiates virtual
 member functions when needed.
  - At the end of the translation unit, Sema tells CodeGen (via the
  ASTConsumer) which vtables must be defined (CodeGen will define
  them) and which may be used (for which CodeGen will define the
  vtables lazily). 

From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).

Notes:
  (1) There's a ton of churn in the tests, because the order in which
  vtables get emitted to IR has changed. I've tried to isolate some of
  the larger tests from these issues.
  (2) Some diagnostics related to
  implicitly-instantiated/implicitly-defined virtual member functions
  have moved to the point of first use/definition. It's better this
  way.
  (3) I could use a review of the places where we MarkVTableUsed, to
  see if I missed any place where the language effectively requires a
  vtable.

Fixes PR7114 and PR6564.

llvm-svn: 103718
2010-05-13 16:44:06 +00:00
Anders Carlsson 174376629a Give thunks the same linkage as their original methods.
llvm-svn: 99729
2010-03-27 20:50:27 +00:00
Anders Carlsson 68fdb871dc Flip the switch and use the new vtable layout code for thunks by default. Add a thunks.cpp test.
llvm-svn: 99367
2010-03-24 00:41:37 +00:00