Commit Graph

13 Commits

Author SHA1 Message Date
Fangrui Song fd739804e0 [test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences
For a default visibility external linkage definition, dso_local is set for ELF
-fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similar
to -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences.

To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition,
which sets dso_local for default visibility external linkage definitions.

To make this flip smooth and enable future (dso_local as definition default),
this patch replaces (function) `define ` with `define{{.*}} `,
(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `.
2020-12-31 00:27:11 -08:00
Fangrui Song dbc96b518b Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"
This reverts commit 789a46f2d7.

Accidentally committed.
2020-02-03 10:09:39 -08:00
Fangrui Song 789a46f2d7 [CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition
Summary:
Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaults
to -fsemantic-interposition).
Users need to specify -fsemantic-interposition to get semantic
interposition behavior.

Semantic interposition is currently a best-effort feature. There may
still be some cases where it is not handled well.

Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfert

Subscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D73865
2020-02-03 09:52:48 -08:00
Matt Arsenault 541bccf4d9 Add testcase from bug 41079
llvm-svn: 356354
2019-03-17 23:16:31 +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
Sanjay Patel 461f2ff445 [builtin_expect] tighten checks, add test, add comments
llvm-svn: 266788
2016-04-19 18:17:34 +00:00
David Blaikie d6c88ece21 [opaque pointer types] Explicit non-pointer type for call expressions
(migration for recent LLVM change to textual IR for calls)

llvm-svn: 235147
2015-04-16 23:25:00 +00:00
Pete Cooper f051cbf631 Don't generate llvm.expect intrinsics with -O0.
The backend won't run LowerExpect on -O0.  In a debug LTO build, this results in llvm.expect intrinsics being in the LTO IR which doesn't know how to optimize them.

Thanks to Chandler for the suggestion and review.

Differential revision: http://reviews.llvm.org/D7183

llvm-svn: 227135
2015-01-26 20:51:58 +00:00
John McCall 9cb88ec8d1 I had meant to locally revert this test.
llvm-svn: 140243
2011-09-21 08:34:49 +00:00
John McCall cbc038a6c3 ANSI C requires that a call to an unprototyped function type succeed
if the definition has a non-variadic prototype with compatible
parameters.  Therefore, the default rule for such calls must be to
use a non-variadic convention.  Achieve this by casting the callee to
the function type with which it is required to be compatible, unless
the target specifically opts out and insists that unprototyped calls
should use the variadic rules.  The only case of that I'm aware of is
the x86-64 convention, which passes arguments the same way in both
cases but also sets a small amount of extra information;  here we seek
to maintain compatibility with GCC, which does set this when calling
an unprototyped function.

Addresses PR10810 and PR10713.

llvm-svn: 140241
2011-09-21 08:08:30 +00:00
Jakub Staszak d2cf2cbae9 Introduce __builtin_expect() intrinsic support.
llvm-svn: 134761
2011-07-08 22:45:14 +00:00
Fariborz Jahanian 5a866c0bf2 Ir-gen the side-effect(s) when __builtin_expect is
constant-folded. // rdar://9330105

llvm-svn: 130163
2011-04-25 22:30:02 +00:00
Fariborz Jahanian 0ebca28f1d 2nd argument of __builtin_expect must be evaluated
if it hs side-effect to matchgcc's behaviour.
Addresses radar 8172109.

llvm-svn: 109467
2010-07-26 23:11:03 +00:00