[Driver] Move -fsemantic-interposition decision from cc1 to driver

And add test/Driver/fsemantic-interposition.c

[Frontend] Delete a redundant check of -pg for setFramePointer()

Driver errors if -fomit-frame-pointer is used together with -pg.
useFramePointerForTargetByDefault() returns true if -pg is specified

[Frontend] Delete a redundant check of -pg for setFramePointer()

Driver errors if -fomit-frame-pointer is used together with -pg.
useFramePointerForTargetByDefault() returns true if -pg is specified.
=>
(!OmitFP && useFramePointerForTargetByDefault(Args, Triple)) is true
=>
We cannot get FramePointerKind::None

show more ...

Implement -fsemantic-interposition

First attempt at implementing -fsemantic-interposition.

Rely on GlobalValue::isInterposable that already captures most of the expected
behavior.

Rely on a Module

Implement -fsemantic-interposition

First attempt at implementing -fsemantic-interposition.

Rely on GlobalValue::isInterposable that already captures most of the expected
behavior.

Rely on a ModuleFlag to state whether we should respect SemanticInterposition or
not. The default remains no.

So this should be a no-op if -fsemantic-interposition isn't used, and if it is,
isInterposable being already used in most optimisation, they should honor it
properly.

Note that it only impacts architecture compiled with -fPIC and no pie.

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

show more ...

Fix conversions in clang and examples

Fix a couple more implicit conversions that Clang doesn't diagnose.

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

Make AST reading work better with LLVM_APPEND_VC_REV=NO

With LLVM_APPEND_VC_REV=NO, Modules/merge-lifetime-extended-temporary.cpp
would fail if it ran before a0f50d731639350c7a7 (which changed
the s

Make AST reading work better with LLVM_APPEND_VC_REV=NO

With LLVM_APPEND_VC_REV=NO, Modules/merge-lifetime-extended-temporary.cpp
would fail if it ran before a0f50d731639350c7a7 (which changed
the serialization format) and then after, for these reasons:

1. With LLVM_APPEND_VC_REV=NO, the module hash before and after the
change was the same.

2. Modules/merge-lifetime-extended-temporary.cpp is the only test
we have that uses -fmodule-cache-path=%t that
a) actually writes to the cache path
b) doesn't do `rm -rf %t` at the top of the test

So the old run would write a module file, and then the new run would
try to load it, but the serialized format changed.

Do several things to fix this:

1. Include clang::serialization::VERSION_MAJOR/VERSION_MINOR in
the module hash, so that when the AST format changes (...and
we remember to bump these), we use a different module cache dir.
2. Bump VERSION_MAJOR, since a0f50d731639350c7a7 changed the
on-disk format in a way that a gch file written before that change
can't be read after that change.
3. Add `rm -rf %t` to all tests that pass -fmodule-cache-path=%t.
This is unnecessary from a correctness PoV after 1 and 2,
but makes it so that we don't amass many cache dirs over time.
(Arguably, it also makes it so that the test suite doesn't catch
when we change the serialization format but don't bump
clang::serialization::VERSION_MAJOR/VERSION_MINOR; oh well.)

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

show more ...

Add a warning, flags and pragmas to limit the number of pre-processor tokens in a translation unit

See
https://docs.google.com/document/d/1xMkTZMKx9llnMPgso0jrx3ankI4cv60xeZ0y4ksf4wc/preview
for bac

Add a warning, flags and pragmas to limit the number of pre-processor tokens in a translation unit

See
https://docs.google.com/document/d/1xMkTZMKx9llnMPgso0jrx3ankI4cv60xeZ0y4ksf4wc/preview
for background discussion.

This adds a warning, flags and pragmas to limit the number of
pre-processor tokens either at a certain point in a translation unit, or
overall.

The idea is that this would allow projects to limit the size of certain
widely included headers, or for translation units overall, as a way to
insert backstops for header bloat and prevent compile-time regressions.

Differential revision: https://reviews.llvm.org/D72703

show more ...

[Frontend] Delete some unneeded CC1 options

[Driver][CodeGen] Support -fpatchable-function-entry=N,M and __attribute__((patchable_function_entry(N,M))) where M>0

Reviewed By: nickdesaulniers

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

[Driver][CodeGen] Support -fpatchable-function-entry=N,M and __attribute__((patchable_function_entry(N,M))) where M>0

Reviewed By: nickdesaulniers

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

show more ...

[Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2a

Now with concepts support merged and mostly complete, we do not need -fconcepts-ts
(which was also misleading as we were not impl

[Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2a

Now with concepts support merged and mostly complete, we do not need -fconcepts-ts
(which was also misleading as we were not implementing the TS) and can enable
concepts features under C++2a. A warning will be generated if users still attempt
to use -fconcepts-ts.

show more ...

[Concepts] Constraint Satisfaction Caching

Add a simple cache for constraint satisfaction results. Whether or not this simple caching
would be permitted in final C++2a is currently being discussed b

[Concepts] Constraint Satisfaction Caching

Add a simple cache for constraint satisfaction results. Whether or not this simple caching
would be permitted in final C++2a is currently being discussed but it is required for
acceptable performance so we use it in the meantime, with the possibility of adding some
cache invalidation mechanisms later.

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

show more ...

Consolidate internal denormal flushing controls

Currently there are 4 different mechanisms for controlling denormal
flushing behavior, and about as many equivalent frontend controls.

- AMDGPU uses

Consolidate internal denormal flushing controls

Currently there are 4 different mechanisms for controlling denormal
flushing behavior, and about as many equivalent frontend controls.

- AMDGPU uses the fp32-denormals and fp64-f16-denormals subtarget features
- NVPTX uses the nvptx-f32ftz attribute
- ARM directly uses the denormal-fp-math attribute
- Other targets indirectly use denormal-fp-math in one DAGCombine
- cl-denorms-are-zero has a corresponding denorms-are-zero attribute

AMDGPU wants a distinct control for f32 flushing from f16/f64, and as
far as I can tell the same is true for NVPTX (based on the attribute
name).

Work on consolidating these into the denormal-fp-math attribute, and a
new type specific denormal-fp-math-f32 variant. Only ARM seems to
support the two different flush modes, so this is overkill for the
other use cases. Ideally we would error on the unsupported
positive-zero mode on other targets from somewhere.

Move the logic for selecting the flush mode into the compiler driver,
instead of handling it in cc1. denormal-fp-math/denormal-fp-math-f32
are now both cc1 flags, but denormal-fp-math-f32 is not yet exposed as
a user flag.

-cl-denorms-are-zero, -fcuda-flush-denormals-to-zero and
-fno-cuda-flush-denormals-to-zero will be mapped to
-fp-denormal-math-f32=ieee or preserve-sign rather than the old
attributes.

Stop emitting the denorms-are-zero attribute for the OpenCL flag. It
has no in-tree users. The meaning would also be target dependent, such
as the AMDGPU choice to treat this as only meaning allow flushing of
f32 and not f16 or f64. The naming is also potentially confusing,
since DAZ in other contexts refers to instructions implicitly treating
input denormals as zero, not necessarily flushing output denormals to
zero.

This also does not attempt to change the behavior for the current
attribute. The LangRef now states that the default is ieee behavior,
but this is inaccurate for the current implementation. The clang
handling is slightly hacky to avoid touching the existing
denormal-fp-math uses. Fixing this will be left for a future patch.

AMDGPU is still using the subtarget feature to control the denormal
mode, but the new attribute are now emitted. A future change will
switch this and remove the subtarget features.

show more ...

[clang][xray] Add -fxray-ignore-loops option

XRay allows tuning by minimum function size, but also always instruments
functions with loops in them. If the minimum function size is set to a
large val

[clang][xray] Add -fxray-ignore-loops option

XRay allows tuning by minimum function size, but also always instruments
functions with loops in them. If the minimum function size is set to a
large value the loop instrumention ends up causing most functions to be
instrumented anyway. This adds a new flag, -fxray-ignore-loops, to disable
the loop detection logic.

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

show more ...

[DebugInfo] Add another level to DebugInfoKind called Constructor

The option will limit debug info by only emitting complete class
type information when its constructor is emitted.
This patch change

[DebugInfo] Add another level to DebugInfoKind called Constructor

The option will limit debug info by only emitting complete class
type information when its constructor is emitted.
This patch changes comparisons with LimitedDebugInfo to use the new
level instead.

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

show more ...

This option allows selecting the TLS size in the local exec TLS model,
which is the default TLS model for non-PIC objects. This allows large/
many thread local variables or a compact/fast code in an

This option allows selecting the TLS size in the local exec TLS model,
which is the default TLS model for non-PIC objects. This allows large/
many thread local variables or a compact/fast code in an executable.

Specification is same as that of GCC. For example, the code model
option precedes the TLS size option.

TLS access models other than local-exec are not changed. It means
supoort of the large code model is only in the local exec TLS model.

Patch By KAWASHIMA Takahiro (kawashima-fj <t-kawashima@fujitsu.com>)
Reviewers: dmgreen, mstorsjo, t.p.northover, peter.smith, ostannard
Reviewd By: peter.smith
Committed by: peter.smith

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

show more ...

[Driver][CodeGen] Add -fpatchable-function-entry=N[,0]

In the backend, this feature is implemented with the function attribute
"patchable-function-entry". Both the attribute and XRay use
TargetOpcod

[Driver][CodeGen] Add -fpatchable-function-entry=N[,0]

In the backend, this feature is implemented with the function attribute
"patchable-function-entry". Both the attribute and XRay use
TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are
incompatible.

Reviewed By: ostannard, MaskRay

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

show more ...

[HIP] Add option --gpu-max-threads-per-block=n

Add this option to change the default launch bounds.

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

Add Triple::isX86()

Reviewed By: craig.topper, skan

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

[NFC] Separate getLastArgIntValue to Basic

getLastArgIntValue is a useful utility function to get command line argument as an integer.
Currently it is in Frontend so that it can only be used by clan

[NFC] Separate getLastArgIntValue to Basic

getLastArgIntValue is a useful utility function to get command line argument as an integer.
Currently it is in Frontend so that it can only be used by clang -cc1. Move it to basic so
that it can also be used by clang driver.

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

show more ...

[Clang FE, SystemZ] Recognize -mrecord-mcount CL option.

Recognize -mrecord-mcount from the command line and add a function attribute
"mrecord-mcount" when passed.

Only valid on SystemZ (when used

[Clang FE, SystemZ] Recognize -mrecord-mcount CL option.

Recognize -mrecord-mcount from the command line and add a function attribute
"mrecord-mcount" when passed.

Only valid on SystemZ (when used with -mfentry).

Review: Ulrich Weigand
https://reviews.llvm.org/D71627

show more ...

Re-land "Add an -fno-temp-file flag for compilation"

This time making sure to initialize FrontendOptions::UseTemporary.

Patch by Zachary Henkel!

Differential revision: https://reviews.llvm.org/D70

Re-land "Add an -fno-temp-file flag for compilation"

This time making sure to initialize FrontendOptions::UseTemporary.

Patch by Zachary Henkel!

Differential revision: https://reviews.llvm.org/D70615

show more ...

Revert "Add an -fno-temp-file flag for compilation"

This reverts commit d129aa1d5369781deff6c6b854cb612e160d3fb2.

This broke the MSan buildbots. More information available in the
original PR: https

Revert "Add an -fno-temp-file flag for compilation"

This reverts commit d129aa1d5369781deff6c6b854cb612e160d3fb2.

This broke the MSan buildbots. More information available in the
original PR: https://reviews.llvm.org/D70615

show more ...

Add an -fno-temp-file flag for compilation

Our build system does not handle randomly named files created during
the build well. We'd prefer to write compilation output directly
without creating a te

Add an -fno-temp-file flag for compilation

Our build system does not handle randomly named files created during
the build well. We'd prefer to write compilation output directly
without creating a temporary file. Function parameters already
existed to control this behavior but were not exposed all the way out
to the command line.

Patch by Zachary Henkel!

Differential revision: https://reviews.llvm.org/D70615

show more ...

[Frontend] Fixes -Wrange-loop-analysis warnings

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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