Commit Graph

5019 Commits

Author SHA1 Message Date
Florian Hahn f999312872
Recommit "[Matrix] Overload stride arg in matrix.columnwise.load/store."
This reverts the revert 28c04794df.

The failing MLIR test that caused the revert should be fixed  in this
version.

Also includes a PPC test fix previously in 1f87c7c478.
2021-08-12 18:31:57 +01:00
Hongtao Yu ccb5b9bbfb [CSSPGO] Allow the use of debug-info-for-profiling and pseudo-probe-for-profiling together
Previoulsy debug-info-for-profiling and pseudo-probe-for-profiling are mutual exclusive because they compete the dwarf discrimnator for callsites on the IR. This changes allows to use the two switches together. The side effect is that callsite discriminators will be taken by pseudo probe, while discriminators for other instructions are still available for AutoFDO use. This is less than ideal, however, it still allows us a chance to smoothly transition from AutoFDO to CSSPGO, by collecting both profiles from a CSSPGO binary.

Reviewed By: wenlei, wmi

Differential Revision: https://reviews.llvm.org/D107876
2021-08-12 08:52:49 -07:00
Mehdi Amini 28c04794df Revert "[Matrix] Overload stride arg in matrix.columnwise.load/store."
This reverts commit a1ef81de35.

Broke the MLIR buildbot.
2021-08-12 11:57:19 +00:00
Florian Hahn a1ef81de35
[Matrix] Overload stride arg in matrix.columnwise.load/store.
This patch adjusts the intrinsics definition of
llvm.matrix.column.major.load and llvm.matrix.column.major.store to
allow overloading the type of the stride. The bitwidth of the stride is
used to perform the offset computation.

This fixes a crash when using __builtin_matrix_column_major_load or
__builtin_matrix_column_major_store on 32 bit platforms. The stride argument
of the builtins are defined as `size_t`, which is 32 bits wide on 32 bit
platforms.

Note that we still perform offset computations with 64 bit width on 32
bit platforms for accesses that do not take a user-specified stride.
This can be fixed separately.

Fixes PR51304.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D107349
2021-08-12 10:45:25 +01:00
Pavel Asyutchenko 7df405e079 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
2021-08-04 16:42:14 -07:00
modimo b40a2a533a [clang] Add support for optional flag -fnew-infallible to restrict exception propagation
The declaration for the global new function in C++ is generated in the compiler front-end. When examining exception propagation, we found that this is the largest root throw site propagator requiring unwind code to be generated for callers up the stack. Allowing this to be handled immediately with termination stops upward propagation and leads to significantly less landing pads generated. This in turns leads to a performance and .text size win.

With `-fnew-infallible` this annotates the declaration with `throw()` and `__attribute__((returns_nonnull))`.  `throw()` allows the compiler to assume exceptions do not propagate out of new and eliminate it as a root throw site. Note that the definition of global new is user-replaceable so users should ensure that the one used follows these semantics.

Measuring internally, we're seeing at 0.5% CPU win in one of our large internal FB workload. Measuring on clang self-build (cd0a1226b5) we get:

thinlto/

        "dwarfehprepare.NumCleanupLandingPadsRemaining": 153494,
        "dwarfehprepare.NumNoUnwind": 26309,
thinlto_newinfallible/

        "dwarfehprepare.NumCleanupLandingPadsRemaining": 143660,
        "dwarfehprepare.NumNoUnwind": 28744,

a 1-143660/153494 = 6.4% reduction in landing pads and a 28744/26309 = 9.3% increase in the number of nounwind functions.

Testing:
ninja check-all
new test case to make sure these attributes are added correctly to global new.

Reviewed By: urnathan

Differential Revision: https://reviews.llvm.org/D105225
2021-08-02 15:45:06 -07:00
Eli Friedman 2a2847823f [ConstantFold] Get rid of special cases for sizeof etc.
Target-dependent constant folding will fold these down to simple
constants (or at least, expressions that don't involve a GEP).  We don't
need heroics to try to optimize the form of the expression before that
happens.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51232 .

Differential Revision: https://reviews.llvm.org/D107116
2021-07-31 13:20:47 -07:00
Fangrui Song 828767f325 COFF/ELF: Place llvm.global_ctors elements in llvm.used if comdat is used
On ELF, an SHT_INIT_ARRAY outside a section group is a GC root. The current
codegen abuses SHT_INIT_ARRAY in a section group to mean a GC root.

On PE/COFF, the dynamic initialization for `__declspec(selectany)` in a comdat
can be garbage collected by `-opt:ref`.

Call `addUsedGlobal` for the two cases to fix the abuse/bug.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D106925
2021-07-28 11:44:19 -07:00
Amy Huang 1a3bf2953a [DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled
Constructor homing reduces the amount of class type info that is emitted
by emitting conmplete type info for a class only when a constructor for
that class is emitted.

This will mainly reduce the amount of duplicate debug info in object
files. In Chrome enabling ctor homing decreased total build directory sizes
by about 30%.

It's also expected that some class types (such as unused classes)
will no longer be emitted in the debug info. This is fine, since we wouldn't
expect to need these types when debugging.

In some cases (e.g. libc++, https://reviews.llvm.org/D98750), classes
are used without calling the constructor. Since this is technically
undefined behavior, enabling constructor homing should be fine.
However Clang now has an attribute
`__attribute__((standalone_debug))` that can be used on classes to
ignore ctor homing.

Bug: https://bugs.llvm.org/show_bug.cgi?id=46537

Differential Revision: https://reviews.llvm.org/D106084
2021-07-26 17:24:42 -07:00
Reid Kleckner a9b114c5dd Disable the new enum i128 test under ASan, it uncovers an existing leak
See llvm.org/pr51221
2021-07-26 15:48:32 -07:00
Reid Kleckner 3230493299 Fix clang debug info irgen of i128 enums
DIEnumerator stores an APInt as of April 2020, so now we don't need to
truncate the enumerator value to 64 bits. Fixes assertions during IRGen.

Split from D105320, thanks to Matheus Izvekov for the test case and
report.

Differential Revision: https://reviews.llvm.org/D106585
2021-07-26 12:25:29 -07:00
Amy Huang 3e2ad26b08 [DebugInfo] Add -fno-ctor-homing for as counterpart to -fuse-ctor-homing
Add an opt out flag for constructor homing.

Differential Revision: https://reviews.llvm.org/D106582
2021-07-22 14:52:36 -07:00
Giorgis Georgakoudis fb0cf01795 Revert "[OpenMP] Codegen aggregate for outlined function captures"
This reverts commit e9c7291cb2.

Fix failing tests
2021-07-19 07:54:26 -07:00
Jamie Schmeiser 73840f9f81 thread_local support for AIX
Summary:
The AIX linker will produce errors on unresolved weak symbols.  Change the
generated code to not check for the initialization function but just call
it and ensure that it always exists.  Also, the AIX atexit routine has a
different name (and signature) so call it correctly.  Update the lit tests
to test on AIX appropriately.

Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: hubert.reinterpretcast (Hubert Tong)
Differential Revision: https://reviews.llvm.org/D104420
2021-07-19 10:03:22 -04:00
David Blaikie dac582ad3a DebugInfo: Name class templates with default arguments consistently (both direct naming, and as a template argument for a function template)
It's noteworthy that GCC has the same bug here, which is a bit
surprising. Both Clang and GCC's bug is only for function template
arguments that are themselves templates with default template arguments
(f1<t1<int[, missing_default_here]>>). Probably because function name
matching isn't generally necessary - whereas type matching is necessary
for DWARF consumers to associate declarations and definitions across
translation units, so the bug's been addressed there already - but
continued to exist for function templates since it's fairly benign
there.

I came across this while working on a change that could reconstitute
these pretty printed names based on the rest of the DWARF, reducing the
size of the DWARF by not having to encode all the template parameters in
the name string. That reconstitution code can't tell the difference
between a defaulted argument or not, so couldn't create the current
buggy-ish output.

Making the names more consistent between direct and indirect references,
and between function and class templates seems all to the good.

(I fixed the function template version of this a few years back in
9fdd09a4cc - clearly I should've looked
more closely and generalized the code better so it only had to be fixed
once - well, doing that here now)
2021-07-17 23:58:15 -07:00
Giorgis Georgakoudis e9c7291cb2 [OpenMP] Codegen aggregate for outlined function captures
Parallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function's argument list. That complicates the fork_call interface in the OpenMP runtime: (1) the fork_call is variadic since there is a variable number of arguments to forward to the outlined function, (2) wrapping/unwrapping arguments happens in the OpenMP runtime, which is sub-optimal, has been a source of ABI bugs, and has a hardcoded limit (16) in the number of arguments, (3)  forwarded arguments must cast to pointer types, which complicates debugging. This patch avoids those issues by aggregating captured arguments in a struct to pass to the fork_call.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D102107
2021-07-16 23:27:44 -07:00
serge-sans-paille 4b219051a3 Fix undeduced type assert
If the instantiation of a member variable makes it possible to
compute a previously undeduced type, we should use that piece of
information.

Fix bug#50590

Differential Revision: https://reviews.llvm.org/D103849
2021-07-15 10:52:25 +02:00
Nikita Popov ff8b1b1b9c Reapply [IR] Don't mark mustprogress as type attribute
Reapply with fixes for clang tests.

-----

This is a simple enum attribute. Test changes are because enum
attributes are sorted before type attributes, so mustprogress is
now in a different position.
2021-07-09 20:57:44 +02:00
Matheus Izvekov 5a1c50410c [clang] fix constexpr code generation for user conversions.
When building the member call to a user conversion function during an
implicit cast, the expression was not being checked for immediate
invocation, so we were never adding the ConstantExpr node to AST.

This would cause the call to the user conversion operator to be emitted
even if it was constantexpr evaluated, and this would even trip an
assert when said user conversion was declared consteval:
`Assertion failed: !cast<FunctionDecl>(GD.getDecl())->isConsteval() && "consteval function should never be emitted", file clang\lib\CodeGen\CodeGenModule.cpp, line 3530`

Fixes PR48855.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D105446
2021-07-08 20:23:19 +02:00
Akira Hatanaka 8db0dbbe2c [CodeGen] Don't create fake FunctionDecls when generating block/byref
copy/dispose helper functions

We found out that these fake functions would cause clang to crash if the
changes proposed in https://reviews.llvm.org/D98799 were made.

The original patch was reverted in f681fd927e
because debug locations were missing in the body of the block byref
helper functions. This patch fixes the bug by calling CreateArtificial
after the calls to StartFunction.

Differential Revision: https://reviews.llvm.org/D104082
2021-06-24 11:45:52 -07:00
modimo 42b99e094c [Clang] Check for returns_nonnull when deciding to add allocation null checks
Non-throwing allocators currently will always get null-check code. However, if the non-throwing allocator is explicitly annotated with returns_nonnull the null check should be elided.

Testing:
ninja check-all
added test case correctly elides

Reviewed By: bruno

Differential Revision: https://reviews.llvm.org/D102820
2021-06-23 17:15:12 -07:00
Zequan Wu f681fd927e Revert "[CodeGen] Don't create fake FunctionDecls when generating block/byref"
That commit causes crash with error "!dbg attachment points at wrong subprogram for function" on iOS platforms.

This reverts commit f4c06bcb67.
2021-06-22 21:48:00 -07:00
Akira Hatanaka f4c06bcb67 [CodeGen] Don't create fake FunctionDecls when generating block/byref
copy/dispose helper functions

We found out that these fake functions would cause clang to crash if the
changes proposed in https://reviews.llvm.org/D98799 were made.

Differential Revision: https://reviews.llvm.org/D104082
2021-06-22 11:42:53 -07:00
Chen Zheng 4590b406c0 [Debug-Info] guard DW_LANG_C_plus_plus_14 under strict dwarf
Reviewed By: stuart

Differential Revision: https://reviews.llvm.org/D104291
2021-06-16 03:17:56 +00:00
Martin Storsjö 6de45b9e6a [clang] Fix reading long doubles with va_arg on x86_64 mingw
On x86_64 mingw, long doubles are always passed indirectly as
arguments (see an existing case in WinX86_64ABIInfo::classify);
generalize the existing code for reading varargs - any non-aggregate
type that is larger than 64 bits (which would be both long double
in mingw, and __int128) are passed indirectly too.

This makes reading varargs consistent with how they're passed,
fixing interop with both gcc and clang callers, for long double
and __int128.

Differential Revision: https://reviews.llvm.org/D103452
2021-06-07 22:34:10 +03:00
Andrew Savonichev b31f41e78b [Clang] Support a user-defined __dso_handle
This fixes PR49198: Wrong usage of __dso_handle in user code leads to
a compiler crash.

When Init is an address of the global itself, we need to track it
across RAUW. Otherwise the initializer can be destroyed if the global
is replaced.

Differential Revision: https://reviews.llvm.org/D101156
2021-06-07 12:54:08 +03:00
Leonard Chan e6f88dc01a [clang][Fuchsia] Turn on relative-vtables by default for Fuchsia
All fuchsia targets will now use the relative-vtables ABI by default.
Also remove -fexperimental-relative-c++-abi-vtables from test RUNs targeting fuchsia.

Differential Revision: https://reviews.llvm.org/D102374
2021-06-01 15:46:09 -07:00
Florian Hahn 5bccdde070
[Matrix] Move C++ matrix cast checks to TryStaticCast.
At the moment, the matrix support in CheckCXXCStyleCast (added in
D101696) breaks function-style constructor calls that take a
single matrix value, because it is treated as matrix cast.

Instead, unify the C++ matrix cast handling by moving the logic to
TryStaticCast and only handle the case where both types are matrix
types. Otherwise, fall back to the generic mis-match detection.

Suggested by @rjmccall

Reviewed By: SaurabhJha

Differential Revision: https://reviews.llvm.org/D103163
2021-05-28 13:00:28 +01:00
Momchil Velikov 21aa107eb7 Reland "Do not create LLVM IR `constant`s for objects with dynamic initialisation"
This relands commit 13dd65b3a1.

The original commit contained a test, which failed when compiled
for a MACH-O target.

This patch changes the test to run for x86_64-linux instead of
`%itanium_abi_triple`, to avoid having invalid syntax for MACH-O
sections. The patch itself does not care about section attribute
syntax and a x86 backend does not even need to be included in the
build.

Differential Revision: https://reviews.llvm.org/D102693
2021-05-25 15:54:40 +01:00
Nico Weber d881319cc5 Revert "Do not create LLVM IR `constant`s for objects with dynamic initialisation"
This reverts commit 13dd65b3a1.
Breaks check-clang on macOS, see https://reviews.llvm.org/D102693
2021-05-24 21:22:07 -04:00
Momchil Velikov 13dd65b3a1 Do not create LLVM IR `constant`s for objects with dynamic initialisation
When a const-qualified object has a section attribute, that
section is set to read-only and clang outputs a LLVM IR constant
for that object. This is incorrect for dynamically initialised
objects.

For example:

    int init() { return 15; }

    __attribute__((section("SA")))
    const int a = init();

a is allocated to a read-only section and is left
unintialised (zero-initialised).

This patch adds checks if an initialiser is a constant expression
and allocates objects to sections as follows:

* const-qualified objects
  - no initialiser or constant initialiser: .rodata
  - dynamic initializer: .bss
* non const-qualified objects
  - no initialiser or dynamic initialiser: .bss
  - constant initialiser: .data

(".rodata", ".data", and ".bss" names used just for explanatory
purpose)

Differential Revision: https://reviews.llvm.org/D102693
2021-05-24 22:04:15 +01:00
Chen Zheng 99d45ed22f [Debug-Info] handle DW_TAG_rvalue_reference_type at strict DWARF.
When -gstrict-dwarf is specified, generate DW_TAG_rvalue_reference_type
at DWARF 4 or above

Reviewed By: dblaikie, aprantl

Differential Revision: https://reviews.llvm.org/D100630
2021-05-23 21:24:13 -04:00
Jinsong Ji edf4d69d38 [AIX] Print printable byte list as quoted string
.byte supports string, so if the whole byte list are printable,
we can actually print the string for readability and LIT tests maintainence.

        .byte 'H,'e,'l,'l,'o,',,' ,'w,'o,'r,'l,'d
->
        .byte "Hello, world"

Reviewed By: hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D102814
2021-05-21 02:37:55 +00:00
Heejin Ahn 3eb12b0ae1 [WebAssembly] Warn on exception spec for Emscripten EH
It turns out we have not correctly supported exception spec all along in
Emscripten EH. Emscripten EH supports `throw()` but not `throw` with
types. See https://bugs.llvm.org/show_bug.cgi?id=50396.

Wasm EH also only supports `throw()` but not `throw` with types, and we
have been printing a warning message for the latter. This prints the
same warning message for `throw` with types when Emscripten EH is used,
or more precisely, when Wasm EH is not used. (So this will print the
warning messsage even when `-fno-exceptions` is used but I think that
should be fine. It's cumbersome to do a complilcated option checking in
CGException.cpp and options checkings are mostly done in elsewhere.)

Reviewed By: dschuff, kripken

Differential Revision: https://reviews.llvm.org/D102791
2021-05-20 13:00:20 -07:00
Jinsong Ji 7d6449322e [DebugInfo][test] Check specific func name to ignore codegen differences
We use `CHECK-LABEL: define` to divide input stream into functions,
this works well on most platforms.

But there are cases that some platforms (eg: AIX) may have different
codegen , especially for global constructor and descructors.

On AIX, the codegen will have two more functions: __dtor_b,
__finalize_b, which will fail the test.

The fix is to use specific function name so that we can safely ignore
those unrelated codegen differences.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D102654
2021-05-18 14:03:27 +00:00
Eli Friedman 698568b74c [clang CodeGen] Don't crash on large atomic function parameter.
I wouldn't recommend writing code like the testcase; a function
parameter isn't atomic, so using an atomic type doesn't really make
sense.  But it's valid, so clang shouldn't crash on it.

The code was assuming hasAggregateEvaluationKind(Ty) implies Ty is a
RecordType, which isn't true.  Just use isRecordType() instead.

Differential Revision: https://reviews.llvm.org/D102015
2021-05-17 13:18:23 -07:00
Danila Kutenin d29f7f1a7b [clang] Fix ternary operator in the second for loop statement
Fix ternary operator in for loop argument, it was by mistake not set as CanBeForRangeDecl and led to incorrect codegen. It fixes https://bugs.llvm.org/show_bug.cgi?id=50038. I don't have commit rights. Danila Kutenin. kutdanila@yandex.ru

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D102502
2021-05-16 10:42:52 -07:00
Saurabh Jha ecb235d940 [Matrix] Implement static cast for matrix types
This patch implements static casts for matrix types. This patch finishes all the work needed for https://bugs.llvm.org/show_bug.cgi?id=47141

Reviewed By: fhahn

Differential Revision: https://reviews.llvm.org/D102125
2021-05-16 08:09:12 +01:00
Roman Lebedev 0d8f91d2a9
[NFC] Delete two newly-added test cases
Failing on bots in unobvious ways.
2021-05-13 21:23:01 +03:00
Roman Lebedev ecc4e9e8f4
[NFC] Try to fix CodeGenCXX/thunk-wrong-return-type.cpp test 2021-05-13 21:17:31 +03:00
cynecx 8ec9fd4839 Support unwinding from inline assembly
I've taken the following steps to add unwinding support from inline assembly:

1) Add a new `unwind` "attribute" (like `sideeffect`) to the asm syntax:

```
invoke void asm sideeffect unwind "call thrower", "~{dirflag},~{fpsr},~{flags}"()
    to label %exit unwind label %uexit
```

2.) Add Bitcode writing/reading support + LLVM-IR parsing.

3.) Emit EHLabels around inline assembly lowering (SelectionDAGBuilder + GlobalISel) when `InlineAsm::canThrow` is enabled.

4.) Tweak InstCombineCalls/InlineFunction pass to not mark inline assembly "calls" as nounwind.

5.) Add clang support by introducing a new clobber: "unwind", which lower to the `canThrow` being enabled.

6.) Don't allow unwinding callbr.

Reviewed By: Amanieu

Differential Revision: https://reviews.llvm.org/D95745
2021-05-13 19:13:03 +01:00
Roman Lebedev 9d3eb7885d
[NFC] Try to fix CodeGenCXX/thunk-wrong-this.cpp test 2021-05-13 21:10:14 +03:00
Roman Lebedev 16d0381841
Return "[CGCall] Annotate `this` argument with alignment"
The original change was reverted because it was discovered
that clang mishandles thunks, and they receive wrong
attributes for their this/return types - the ones for the function
they will call, not the ones they have.

While i have tried to fix this in https://reviews.llvm.org/D100388
that patch has been up and stuck for a month now,
with little signs of progress.

So while it will be good to solve this for real,
for now we can simply avoid introducing the bug,
by not annotating this/return for thunks.

This reverts commit 6270b3a1ea,
relanding 0aa0458f14.
2021-05-13 20:33:14 +03:00
Roman Lebedev a624cec56d
[Clang][Codegen] Do not annotate thunk's this/return types with align/deref/nonnull attrs
As it was discovered in post-commit feedback
for 0aa0458f14,
we handle thunks incorrectly, and end up annotating
their this/return with attributes that are valid
for their callees, not for thunks themselves.

While it would be good to fix this properly,
and keep annotating them on thunks,
i've tried doing that in https://reviews.llvm.org/D100388
with little success, and the patch is stuck for a month now.

So for now, as a stopgap measure, subj.
2021-05-13 20:33:08 +03:00
Roman Lebedev 70aa4623de
[NFC][Clang][Codegen] Add tests with wrong attributes on this/return of thunks
From https://reviews.llvm.org/D100388
2021-05-13 20:32:40 +03:00
Richard Smith 4c88cfb1dc Add test for substitutability of variable templates in closure type
mangling.
2021-05-12 18:45:33 -07:00
Richard Smith 5bb7e81c64 Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope.
This implements the direction proposed in
https://github.com/itanium-cxx-abi/cxx-abi/pull/126.

Differential Revision: https://reviews.llvm.org/D101968
2021-05-12 13:13:21 -07:00
Pratyush Das 99d63ccff0 Add type information to integral template argument if required.
Non-comprehensive list of cases:
 * Dumping template arguments;
 * Corresponding parameter contains a deduced type;
 * Template arguments are for a DeclRefExpr that hadMultipleCandidates()

Type information is added in the form of prefixes (u8, u, U, L),
suffixes (U, L, UL, LL, ULL) or explicit casts to printed integral template
argument, if MSVC codeview mode is disabled.

Differential revision: https://reviews.llvm.org/D77598
2021-05-12 19:00:08 +00:00
Richard Smith bb726383ac Revert "Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope."
This reverts commit 697ac15a0f, for which
review was not complete. That change was accidentally pushed when
an unrelated change was pushed.
2021-05-11 17:46:18 -07:00
Richard Smith 697ac15a0f Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope.
This implements the direction proposed in
https://github.com/itanium-cxx-abi/cxx-abi/pull/126.

Differential Revision: https://reviews.llvm.org/D101968
2021-05-11 17:35:33 -07:00