History log of /llvm-project-15.0.7/clang/lib/CodeGen/CodeGenModule.cpp (Results 126 – 150 of 1864)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# c3717b68 16-Sep-2021 serge-sans-paille <[email protected]>

Simplify handling of builtin with inline redefinition

(This is a recommit of 3d6f49a56995b845 that should no longer break validation since
bd379915de38a9af3d65e1).

It is a common practice in glibc

Simplify handling of builtin with inline redefinition

(This is a recommit of 3d6f49a56995b845 that should no longer break validation since
bd379915de38a9af3d65e1).

It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified function.

Clang currently has an imperfect approach to the problem, using a combination of
trivially recursive function detection and noinline attribute.

Simplify the logic by suffixing these functions by `.inline` during codegen, so
that they are not recognized as builtin by llvm.

After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite

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

show more ...


# 0d76d483 28-Sep-2021 Kevin Athey <[email protected]>

Revert "Simplify handling of builtin with inline redefinition"

This reverts commit 3d6f49a56995b845c40be5827ded5d1e3f692cec.

Broke bot: https://lab.llvm.org/buildbot/#/builders/5/builds/12360


# 3d6f49a5 16-Sep-2021 serge-sans-paille <[email protected]>

Simplify handling of builtin with inline redefinition

It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified funct

Simplify handling of builtin with inline redefinition

It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified function.

Clang currently has an imperfect approach to the problem, using a combination of
trivially recursive function detection and noinline attribute.

Simplify the logic by suffixing these functions by `.inline` during codegen, so
that they are not recognized as builtin by llvm.

After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite

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

show more ...


# e3b10525 16-Sep-2021 Erich Keane <[email protected]>

Make multiversioning work with internal linkage

We previously made all multiversioning resolvers/ifuncs have weak
ODR linkage in IR, since we NEED to emit the whole resolver every time
we see a call

Make multiversioning work with internal linkage

We previously made all multiversioning resolvers/ifuncs have weak
ODR linkage in IR, since we NEED to emit the whole resolver every time
we see a call, but it is not necessarily the place where all the
definitions live.

HOWEVER, when doing so, we neglected the case where the versions have
internal linkage. This patch ensures we do this, so you don't get weird
behavior with static functions.

show more ...


# f9bc1b3b 24-Aug-2021 Justas Janickas <[email protected]>

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapp

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapping between
C++ for OpenCL versions and their corresponding compatible OpenCL
versions. This mapping function should be updated each time a new
C++ for OpenCL language version is introduced. The helper function
is expected to simplify conditions on OpenCL C and C++ for OpenCL
versions inside compiler code.

Code refactoring performed.

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

show more ...


# 1724a164 30-Aug-2021 Andrei Elovikov <[email protected]>

[NFC][clang] Move IR-independent parts of target MV support to X86TargetParser.cpp

...that is located under llvm/lib/Support/.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.o

[NFC][clang] Move IR-independent parts of target MV support to X86TargetParser.cpp

...that is located under llvm/lib/Support/.

Reviewed By: erichkeane

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

show more ...


# 7cab90a7 26-Aug-2021 Alex Richardson <[email protected]>

Fix __attribute__((annotate("")) with non-zero globals AS

The existing code attempting to bitcast from a value in the default globals AS
to i8 addrspace(0)* was triggering an assertion failure in ou

Fix __attribute__((annotate("")) with non-zero globals AS

The existing code attempting to bitcast from a value in the default globals AS
to i8 addrspace(0)* was triggering an assertion failure in our downstream fork.
I found this while compiling poppler for CHERI-RISC-V (we use AS200 for all
globals). The test case uses AMDGPU since that is one of the in-tree targets
with a non-zero default globals address space.
The new test previously triggered a "Invalid constantexpr bitcast!" assertion
and now correctly generates code with addrspace(1) pointers.

Reviewed By: rjmccall

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

show more ...


# 846e562d 25-Aug-2021 Nick Desaulniers <[email protected]>

[Clang] add support for error+warning fn attrs

Add support for the GNU C style __attribute__((error(""))) and
__attribute__((warning(""))). These attributes are meant to be put on
declarations of fu

[Clang] add support for error+warning fn attrs

Add support for the GNU C style __attribute__((error(""))) and
__attribute__((warning(""))). These attributes are meant to be put on
declarations of functions whom should not be called.

They are frequently used to provide compile time diagnostics similar to
_Static_assert, but which may rely on non-ICE conditions (ie. relying on
compiler optimizations). This is also similar to diagnose_if function
attribute, but can diagnose after optimizations have been run.

While users may instead simply call undefined functions in such cases to
get a linkage failure from the linker, these provide a much more
ergonomic and actionable diagnostic to users and do so at compile time
rather than at link time. Users instead may be able use inline asm .err
directives.

These are used throughout the Linux kernel in its implementation of
BUILD_BUG and BUILD_BUG_ON macros. These macros generally cannot be
converted to use _Static_assert because many of the parameters are not
ICEs. The Linux kernel still needs to be modified to make use of these
when building with Clang; I have a patch that does so I will send once
this feature is landed.

To do so, we create a new IR level Function attribute, "dontcall" (both
error and warning boil down to one IR Fn Attr). Then, similar to calls
to inline asm, we attach a !srcloc Metadata node to call sites of such
attributed callees.

The backend diagnoses these during instruction selection, while we still
know that a call is a call (vs say a JMP that's a tail call) in an arch
agnostic manner.

The frontend then reconstructs the SourceLocation from that Metadata,
and determines whether to emit an error or warning based on the callee's
attribute.

Link: https://bugs.llvm.org/show_bug.cgi?id=16428
Link: https://github.com/ClangBuiltLinux/linux/issues/1173

Reviewed By: aaron.ballman

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

show more ...


# ea08c4cd 20-Aug-2021 Jonas Hahnfeld <[email protected]>

[CUDA] Fix static device variables with -fgpu-rdc

NVPTX does not allow dots in the identifier, so ptxas errors out with
fatal : Parsing error near '.static': syntax error
because it parses .sta

[CUDA] Fix static device variables with -fgpu-rdc

NVPTX does not allow dots in the identifier, so ptxas errors out with
fatal : Parsing error near '.static': syntax error
because it parses .static as a directive. Avoid this problem by using
two underscores, similar to what OpenMP does for outlined functions.

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

show more ...


# 8da70fed 04-Aug-2021 Andy Wingo <[email protected]>

[clang][NFC] Tighten up code for GetGlobalVarAddressSpace

The LangAS local is only used in the OpenCL case; move its decl
inwards.

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


# d3d4d985 04-Aug-2021 Andy Wingo <[email protected]>

[clang][NFC] GetOrCreateLLVMGlobal takes LangAS

Pass a LangAS instead of a target address space to
GetOrCreateLLVMGlobal, to remove a place where the frontend assumes that
target address space 0 is

[clang][NFC] GetOrCreateLLVMGlobal takes LangAS

Pass a LangAS instead of a target address space to
GetOrCreateLLVMGlobal, to remove a place where the frontend assumes that
target address space 0 is special.

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

show more ...


# de0ae9e8 17-Aug-2021 Arthur Eubanks <[email protected]>

[NFC] Cleanup more AttributeList::addAttribute()


# ad727ab7 17-Aug-2021 Arthur Eubanks <[email protected]>

[NFC] Migrate some callers away from Function/AttributeLists methods that take an index

These methods can be confusing.


# 46cf8253 16-Aug-2021 Arthur Eubanks <[email protected]>

[NFC] Replace Function handling of attributes with less confusing calls

To avoid magic constants and confusing indexes.


# 8e9ffa1d 13-Aug-2021 Arthur Eubanks <[email protected]>

[NFC] Cleanup callers of AttributeList::hasAttributes()

AttributeList::hasAttributes() is confusing, use clearer methods like
hasFnAttrs().


# 80ea2bb5 13-Aug-2021 Arthur Eubanks <[email protected]>

[NFC] Rename AttributeList::getParam/Ret/FnAttributes() -> get*Attributes()

This is more consistent with similar methods.


# 6ec36d18 08-Aug-2021 Michael Liao <[email protected]>

[cuda] Mark builtin texture/surface reference variable as 'externally_initialized'.

- They need to be preserved even if there's no reference within the
device code as the host code may need to ini

[cuda] Mark builtin texture/surface reference variable as 'externally_initialized'.

- They need to be preserved even if there's no reference within the
device code as the host code may need to initialize them based on the
application logic.

Reviewed By: tra

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

show more ...


# 7df405e0 04-Aug-2021 Pavel Asyutchenko <[email protected]>

Apply -fmacro-prefix-map to __builtin_FILE()

This matches the behavior of GCC.
Patch does not change remapping logic itself, so adding one simple smoke test should be enough.

Reviewed By: MaskRay

Apply -fmacro-prefix-map to __builtin_FILE()

This matches the behavior of GCC.
Patch does not change remapping logic itself, so adding one simple smoke test should be enough.

Reviewed By: MaskRay

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

show more ...


# 44dbbe61 19-Jul-2021 Yaxun (Sam) Liu <[email protected]>

[HIP] Preserve ASAN bitcode library functions

Address sanitizer passes may generate call of ASAN bitcode library
functions after bitcode linking in lld, therefore lld cannot add
those symbols since

[HIP] Preserve ASAN bitcode library functions

Address sanitizer passes may generate call of ASAN bitcode library
functions after bitcode linking in lld, therefore lld cannot add
those symbols since it does not know they will be used later.

To solve this issue, clang emits a reference to a bicode library
function which calls all ASAN functions which need to be
preserved. This basically force all ASAN functions to be
linked in.

Reviewed by: Artem Belevich

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

show more ...


# 9ce02ea8 24-Jun-2021 Joseph Huber <[email protected]>

[OpenMP] Add Module metadata for OpenMP compilation

This patch adds a module level metadata flag indicating that the module
was compiled with the `-fopenmp` flag. This will make it easier for
passes

[OpenMP] Add Module metadata for OpenMP compilation

This patch adds a module level metadata flag indicating that the module
was compiled with the `-fopenmp` flag. This will make it easier for
passes like OpenMPOpt to determine if it should be run.

Reviewed By: jdoerfert

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

show more ...


# 8ace1213 21-Jun-2021 Nick Desaulniers <[email protected]>

[IR] convert warn-stack-size from module flag to fn attr

Otherwise, this causes issues when building with LTO for object files
that use different values.

Link: https://github.com/ClangBuiltLinux/li

[IR] convert warn-stack-size from module flag to fn attr

Otherwise, this causes issues when building with LTO for object files
that use different values.

Link: https://github.com/ClangBuiltLinux/linux/issues/1395

Reviewed By: dblaikie, MaskRay

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

show more ...


# 61cdaf66 11-Jun-2021 Simon Pilgrim <[email protected]>

[ADT] Remove APInt/APSInt toString() std::string variants

<string> is currently the highest impact header in a clang+llvm build:

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm

[ADT] Remove APInt/APSInt toString() std::string variants

<string> is currently the highest impact header in a clang+llvm build:

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps.

This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code.

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

show more ...


# fc018ebb 10-Jun-2021 Nick Desaulniers <[email protected]>

[IR] make -warn-frame-size into a module attr

-Wframe-larger-than= is an interesting warning; we can't know the frame
size until PrologueEpilogueInsertion (PEI); very late in the compilation
pipelin

[IR] make -warn-frame-size into a module attr

-Wframe-larger-than= is an interesting warning; we can't know the frame
size until PrologueEpilogueInsertion (PEI); very late in the compilation
pipeline.

-Wframe-larger-than= was propagated through CC1 as an -mllvm flag, then
was a cl::opt in LLVM's PEI pass; this meant it was dropped during LTO
and needed to be re-specified via -plugin-opt.

Instead, make it part of the IR proper as a module level attribute,
similar to D103048. Introduce -fwarn-stack-size CC1 option.

Reviewed By: rsmith, qcolombet

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

show more ...


# b2d0c16e 05-May-2021 Nathan Sidwell <[email protected]>

[clang] p1099 using enum part 2

This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is th

[clang] p1099 using enum part 2

This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the
new class set up.

There is one case where we accept ill-formed, but I believe this is
merely an extended case of an existing bug, so consider it
orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using
decls can bring in the same target decl ([namespace.udecl]/8). But we
already accept:

struct A { enum { a }; };
struct B : A { using A::a; };
struct C : B { using A::a;
using B::a; }; // same enumerator

this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.

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

show more ...


# 3787ee45 08-Jun-2021 Nick Desaulniers <[email protected]>

reland [IR] make -stack-alignment= into a module attr

Relands commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for
MIPS.

Similar to D102742, specifying the stack alignment via CodegenOpts

reland [IR] make -stack-alignment= into a module attr

Relands commit 433c8d950cb3a1fa0977355ce0367e8c763a3f13 with fixes for
MIPS.

Similar to D102742, specifying the stack alignment via CodegenOpts means
that this flag gets dropped during LTO, unless the command line is
re-specified as a plugin opt. Instead, encode this information as a
module level attribute so that we don't have to expose this llvm
internal flag when linking the Linux kernel with LTO.

Looks like external dependencies might need a fix:
* https://github.com/llvm-hs/llvm-hs/issues/345
* https://github.com/halide/Halide/issues/6079

Link: https://github.com/ClangBuiltLinux/linux/issues/1377

Reviewed By: tejohnson

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

show more ...


12345678910>>...75