Commit Graph

543 Commits

Author SHA1 Message Date
Marco Elver 280333021e [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute
We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Linux-kernel
mailing lists, because we currently do workarounds using objtool to
remove coverage instrumentation. Since that support is only on x86, to
continue support coverage instrumentation on other architectures, we
must support selectively disabling coverage instrumentation via function
attributes.

Unfortunately, for SanitizeCoverage, it has not been implemented as a
sanitizer via fsanitize= and associated options in Sanitizers.def, but
rolls its own option fsanitize-coverage. This meant that we never got
"automatic" no_sanitize attribute support.

Implement no_sanitize attribute support by special-casing the string
"coverage" in the NoSanitizeAttr implementation. To keep the feature as
unintrusive to existing IR generation as possible, define a new negative
function attribute NoSanitizeCoverage to propagate the information
through to the instrumentation pass.

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

Reviewed By: vitalybuka, morehouse

Differential Revision: https://reviews.llvm.org/D102772
2021-05-25 12:57:14 +02: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
Josh Berdine f4d156aed0 [NFC][OCaml] Reformat to clean up following CAMLprim removal
The removal of CAMLprim left the code in need of an application of
clang-format. There are various other changes made by clang-format
which it seems ought to be rolled together into this diff.

Differential Revision: https://reviews.llvm.org/D99477
2021-04-05 10:55:08 +01:00
Josh Berdine 8e4fc55a0e [NFC][OCaml] Remove vestigial CAMLprim declarations
The CAMLprim macro has not been needed since OCaml 3.11, and is
defined to the empty string. This diff removes all instances of it.

Differential Revision: https://reviews.llvm.org/D99476
2021-04-05 10:55:08 +01:00
Josh Berdine d9bbd98645 [OCaml] Omit unnecessary GC root registrations
The current code does not follow the simple interface to the OCaml GC,
where GC roots are registered conservatively, only initializing
allocations are performed, etc. This is intentional, as stated in the
opening file comments. On the other hand, the current code does
register GC roots in many situations where it is not strictly
necessary. This diff omits many of them.

Differential Revision: https://reviews.llvm.org/D99475
2021-04-05 10:55:07 +01:00
Josh Berdine 2c82ea1849 [OCaml] Code simplification using string allocation functions
Using the `cstr_to_string` function that allocates and initializes an
OCaml `string` value enables simplifications in several cases. This
change also has the effect of avoiding calling `memcpy` on NULL
pointers even if only 0 bytes are to be copied.

Differential Revision: https://reviews.llvm.org/D99474
2021-04-05 10:55:07 +01:00
Josh Berdine e5b7fedc57 [OCaml] Code simplification using option allocation functions
Using the `caml_alloc_some` and `ptr_to_option` functions that
allocate OCaml `option` values enables simplifications in many
cases. These simplifications also result in avoiding unnecessary
double initialization in many cases, so yield a minor optimization as
well.

Also, change to avoid using the old unprefixed functions such as
`alloc_small` and instead use the current `caml_alloc_small`.

A few of the changed functions were slightly rewritten in the
early-return style.

Differential Revision: https://reviews.llvm.org/D99473
2021-04-05 10:55:07 +01:00
Josh Berdine 58bb9222dd [OCaml] Minor optimizations by avoiding double initialization
In several functions an OCaml block is allocated and no further OCaml
allocation functions (or other functions that might trigger allocation
or collection) are performed before the block is fully initialized. In
these cases, it is safe and slightly more efficient to allocate an
uninitialized block.

Also, the code does not become more complex after the non-initializing
allocation, since in the case that a non-small allocation is made, the
initial values stored are definitely not pointers to OCaml young
blocks, and so initializing via direct assignment is still safe. That
is, in general if `caml_alloc_small` is called, initializing it with
direct assignments is safe, but if `caml_alloc_shr` is
called (e.g. for a block larger than `Max_young_wosize`), then
`caml_initialize` should be called to inform the GC of a potential
major to minor pointer. But if the initial value is definitely not a
young OCaml block, direct assignment is safe.

Differential Revision: https://reviews.llvm.org/D99472
2021-04-05 10:55:07 +01:00
Josh Berdine 5c25ff8739 [OCaml] Fix unsafe uses of Store_field
Using `Store_field` to initialize fields of blocks allocated with
`caml_alloc_small` is unsafe. The fields of blocks allocated by
`caml_alloc_small` are not initialized, and `Store_field` calls the
OCaml GC write barrier. If the uninitialized value of a field happens
to point into the OCaml heap, then it will e.g. be added to a conflict
set or followed and have what the GC thinks are color bits
changed. This leads to crashes or memory corruption.

This diff fixes a few (I think all) instances of this problem. Some of
these are creating option values. OCaml 4.12 has a dedicated
`caml_alloc_some` function for this, so this diff adds a compatible
function with a version check to avoid conflict. With that, macros for
accessing option values are also added.

Differential Revision: https://reviews.llvm.org/D99471
2021-04-05 10:55:07 +01:00
Matt Arsenault 9a0c9402fa Reapply "OpaquePtr: Turn inalloca into a type attribute"
This reverts commit 07e46367ba.
2021-03-29 08:55:30 -04:00
Vaivaswatha Nagaraj 11f59c5457 [OCaml][Test] Fix and enable debuginfo.ml test
`get_or_create_type_array` was used on a non-type MDNode.
Add interface for `get_or_create_array` and use that instead.

Differential Revision: https://reviews.llvm.org/D99450
2021-03-28 06:25:39 +05:30
Josh Berdine d50fe9f0d6 [NFC][OCaml] Resolve a couple more compilation warnings
Followup to: 0b1dc49ca3 [NFC][OCaml] Resolve const and unsigned compilation warnings

Differential Revision: https://reviews.llvm.org/D99420
2021-03-26 20:56:19 +00:00
Vaivaswatha Nagaraj c244cd7217 [OCaml][DebugInfo] Add tests for debug info API
In the process of adding the tests, several bugs were
found in the implementation and interface of the API
and they were fixed.

Some utilities from the core tests (core.ml) were moved
into a separate file for reuse.

The following new functions have been added:
`dibuild_create_global_variable_expression`,
`dibuild_create_constant_value_expression` and
`llmetadata_null`. The third one already existed but
is now exposed publicly.

Differential Revision: https://reviews.llvm.org/D99403
2021-03-26 22:06:48 +05:30
Josh Berdine 6f77926f46 [OCaml] Fix a possible crash in llvm_struct_name
The implementation of `llvm_struct_name` before this diff calls
`caml_copy_string`, which allocates, while the `result` local variable
points to a block allocated by `caml_alloc_small` that has not yet
been initialized. If the allocation in `caml_copy_string` triggers a
garbage collection, then the GC root `result` contains a pointer to
uninitialized data, which may crash the GC or lead to a memory
corruption.

This diff fixes this by allocating and initializing the string first
and then allocating and initializing the option, thereby leaving no
dangling pointers when allocations are made.

The conversion from a C string to an OCaml string option is refactored
into a function, `cstr_to_string_option`. This function is also used
to simplify the definitions of `llvm_get_mdstring` and
`llvm_string_of_const`.

Differential Revision: https://reviews.llvm.org/D99393
2021-03-26 11:49:13 +00:00
Josh Berdine 0b1dc49ca3 [NFC][OCaml] Resolve const and unsigned compilation warnings
There are a number of compilation warnings regarding disregarding
const qualifiers, and casting between pointers to integer types with
different sign.

The incompatible sign warnings are due to treating the result of
`LLVMGetModuleIdentifier` as `const unsigned char *`, but it is
declared as `const char *`.

The dropped const qualifiers are due to the code pattern
`memcpy(String_val(_),_,_)` which ought to be (following the
implementation of the OCaml runtime)
`memcpy((char *)String_val(_),_,_)`. The issue is that `String_val` is
usually used to get the value of an immutable string. But in the
context of the `memcpy` calls, the string is in the process of being
initialized, so is not yet constant.

Differential Revision: https://reviews.llvm.org/D99392
2021-03-26 11:49:13 +00:00
Josh Berdine b06c669114 [NFC][OCaml] Simplify llvm_global_initializer using ptr_to_option
This diff uses ptr_to_option to convert a nullable C pointer to an
OCaml option instead of the redundant implementation in
llvm_global_initializer.

Differential Revision: https://reviews.llvm.org/D99391
2021-03-26 11:49:13 +00:00
Vaivaswatha Nagaraj f860187ea6 [OCaml] Add (get/set)_module_identifer functions
Also:

- Fix a bug that crept in when fixing a buildbot failure in
f7be9db622
- Use mlsize_t for cstr_to_string as that is what
caml_alloc_string specifies.

Differential Revision: https://reviews.llvm.org/D98851
2021-03-20 20:41:51 +05:30
Timotej Kapus 2571a09367 [OCaml] Handle nullptr in Llvm.global_initializer
LLVMGetInitializer returns nullptr in case there is no initializer.
There is not much that can be done with nullptr in OCaml, not even
test if it is null. Also, there does not seem to be a C or OCaml API
to test if there is an initializer. So this diff changes
Llvm.global_initializer to return an option.

Reviewed By: whitequark

Differential Revision: https://reviews.llvm.org/D65195
2021-03-17 13:39:35 +00:00
Jason Hu cca3167de0 [NFC][OCaml] Fix documentation for verify_function and const_of_int64
Documentation of verify_function is incorrect and that of
const_of_int64 is incomplete.

Reviewed By: whitequark

Differential Revision: https://reviews.llvm.org/D77884
2021-03-17 12:09:28 +00:00
Vaivaswatha Nagaraj f7be9db622 [OCaml] Fix buildbot failure in OCaml tests
The commit 506df1bbfd introduced
a call to `caml_alloc_initialized_string` which seems to be
unavailable on older OCaml versions. So I'm now switching to
using `caml_alloc_string` and using a `memcpy` after that, as
is done in the rest of the file.

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/16/builds/7919
2021-03-17 11:29:55 +05:30
Vaivaswatha Nagaraj 506df1bbfd [OCaml] DebugInfo support for OCaml bindings
Many (but not all) DebugInfo functions are now added to the
OCaml bindings, and rest can be safely added incrementally.

Differential Revision: https://reviews.llvm.org/D90831
2021-03-17 10:15:56 +05:30
Josh Berdine ece6d8e72e [OCaml] Add missing TypeKinds, Opcode, and AtomicRMWBinOps
There are several enum values that have been added to LLVM-C that are
missing from the OCaml bindings. The types defined in
bindings/ocaml/llvm/llvm.ml should be in sync with the corresponding
enum definitions in include/llvm-c/Core.h. The enum values are passed
from C to OCaml unmodified, and clients of the OCaml bindings
interpret them as tags of the corresponding OCaml types. So the only
changes needed are to add the missing constructors to the type
definitions, and to change the name of the maximum opcode in an
assertion.

Differential Revision: https://reviews.llvm.org/D98578
2021-03-16 15:32:38 +00:00
Fangrui Song 0f10a26dd4 [Go] Fix bindings/go/llvm/IRBindings.cpp 2020-12-16 10:09:58 -08:00
Fangrui Song 8c4e55762d [docs][unittest][Go][StackProtector] Migrate deprecated DebugInfo::get to DILocation::get 2020-12-15 14:17:04 -08:00
Zhengyang Liu 75f50e15bf Adding PoisonValue for representing poison value explicitly in IR
Define ConstantData::PoisonValue.
Add support for poison value to LLLexer/LLParser/BitcodeReader/BitcodeWriter.
Add support for poison value to llvm-c interface.
Add support for poison value to OCaml binding.
Add m_Poison in PatternMatch.

Differential Revision: https://reviews.llvm.org/D71126
2020-11-25 17:33:51 -07:00
Nick Desaulniers f4c6080ab8 Revert "[IR] add fn attr for no_stack_protector; prevent inlining on mismatch"
This reverts commit b7926ce6d7.

Going with a simpler approach.
2020-11-17 17:27:14 -08:00
serge-sans-paille 95537f4508 llvmbuildectomy - compatibility with ocaml bindings
Use exact component name in add_ocaml_library.
Make expand_topologically compatible with new architecture.
Fix quoting in is_llvm_target_library.
Fix LLVMipo component name.
Write release note.
2020-11-13 14:35:52 +01:00
serge-sans-paille 9218ff50f9 llvmbuildectomy - replace llvm-build by plain cmake
No longer rely on an external tool to build the llvm component layout.

Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.

These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.

Differential Revision: https://reviews.llvm.org/D90848
2020-11-13 10:35:24 +01:00
Nick Desaulniers b7926ce6d7 [IR] add fn attr for no_stack_protector; prevent inlining on mismatch
It's currently ambiguous in IR whether the source language explicitly
did not want a stack a stack protector (in C, via function attribute
no_stack_protector) or doesn't care for any given function.

It's common for code that manipulates the stack via inline assembly or
that has to set up its own stack canary (such as the Linux kernel) would
like to avoid stack protectors in certain functions. In this case, we've
been bitten by numerous bugs where a callee with a stack protector is
inlined into an __attribute__((__no_stack_protector__)) caller, which
generally breaks the caller's assumptions about not having a stack
protector. LTO exacerbates the issue.

While developers can avoid this by putting all no_stack_protector
functions in one translation unit together and compiling those with
-fno-stack-protector, it's generally not very ergonomic or as
ergonomic as a function attribute, and still doesn't work for LTO. See also:
https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/
https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/T/#u

Typically, when inlining a callee into a caller, the caller will be
upgraded in its level of stack protection (see adjustCallerSSPLevel()).
By adding an explicit attribute in the IR when the function attribute is
used in the source language, we can now identify such cases and prevent
inlining.  Block inlining when the callee and caller differ in the case that one
contains `nossp` when the other has `ssp`, `sspstrong`, or `sspreq`.

Fixes pr/47479.

Reviewed By: void

Differential Revision: https://reviews.llvm.org/D87956
2020-10-23 11:55:39 -07:00
Fangrui Song 63c58c2b93 [bindings/go] Fix TestAttributes after D88241 2020-09-25 20:31:45 -07:00
Arthur Eubanks dd04fa17d7 [OCaml] Remove add_constant_propagation
After https://reviews.llvm.org/D85159.
2020-08-27 09:30:21 -07:00
Arthur Eubanks 486ed88533 [ConstProp] Remove ConstantPropagation
As discussed in
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143801.html.

Currently no users outside of unit tests.

Replace all instances in tests of -constprop with -instsimplify.
Notable changes in tests:
* vscale.ll - @llvm.sadd.sat.nxv16i8 is evaluated by instsimplify, use a fake intrinsic instead
* InsertElement.ll - insertelement undef is removed by instsimplify in @insertelement_undef
llvm/test/Transforms/ConstProp moved to llvm/test/Transforms/InstSimplify/ConstProp

Reviewed By: lattner, nikic

Differential Revision: https://reviews.llvm.org/D85159
2020-08-26 15:51:30 -07:00
Florian Hahn 4ffa6a27ac [Bindings] Remove ipc_propagation.
IPConstantPropagation has been removed, also remove the bindings.
2020-08-02 22:36:53 +01:00
Florian Hahn 599955eb56 Recommit "[IPConstProp] Remove and move tests to SCCP."
This reverts commit 59d6e814ce.

The cause for the revert (3 clang tests running opt -ipconstprop) was
fixed by removing those lines.
2020-08-02 22:23:54 +01:00
Florian Hahn 59d6e814ce Revert "[IPConstProp] Remove and move tests to SCCP."
This reverts commit e77624a3be.

Looks like some clang tests manually invoke -ipconstprop via opt.....
2020-07-30 13:06:54 +01:00
Florian Hahn e77624a3be [IPConstProp] Remove and move tests to SCCP.
As far as I know, ipconstprop has not been used in years and ipsccp has
been used instead. This has the potential for confusion and sometimes
leads people to spend time finding & reporting bugs as well as
updating it to work with the latest API changes.

This patch moves the tests over to SCCP. There's one functional difference
I am aware of: ipconstprop propagates for each call-site individually, so
for functions that are called with different constant arguments it can sometimes
produce better results than ipsccp (at much higher compile-time cost).But
IPSCCP can be thought to do so as well for internal functions and as mentioned
earlier, the pass seems unused in practice (and there are no plans on working
towards enabling it anytime).

Also discussed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143773.html

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D84447
2020-07-30 12:36:27 +01:00
Arthur Eubanks 71d0a2b8a3 [DFSan][NewPM] Port DataFlowSanitizer to NewPM
Reviewed By: ychen, morehouse

Differential Revision: https://reviews.llvm.org/D84707
2020-07-29 10:19:15 -07:00
Eric Christopher 80af39ead8 Fix go bindings after FixedVectorType -> VectorType change. 2020-05-15 16:37:57 -07:00
Benjamin Kramer 6bec6a9755 Update go bindings for 2dea3f1298 2020-04-22 19:02:59 +02:00
Adrian Prantl e4e7e44765 Add an SDK attribute to DICompileUnit
This is part of PR44213 https://bugs.llvm.org/show_bug.cgi?id=44213

When importing (system) Clang modules, LLDB needs to know which SDK
(e.g., MacOSX, iPhoneSimulator, ...) they came from. While the sysroot
attribute contains the absolute path to the SDK, this doesn't work
well when the debugger is run on a different machine than the
compiler, and the SDKs are installed in different directories. It thus
makes sense to just store the name of the SDK instead of the absolute
path, so it can be found relative to LLDB.

rdar://problem/51645582

Differential Revision: https://reviews.llvm.org/D75646
2020-03-11 14:14:06 -07:00
Ayke van Laethem 2a7a989c3e
[LLVM-C] Add bindings for addCoroutinePassesToExtensionPoints
This patch adds bindings to C and Go for
addCoroutinePassesToExtensionPoints, which is used to add coroutine
passes to the correct locations in PassManagerBuilder.

Differential Revision: https://reviews.llvm.org/D51642
2020-02-24 20:15:51 +01:00
Ayke van Laethem 00570c2f18
[bindings/go] Add RemoveFromParentAsInstruction
This allows removing instructions without erasing them. They can then be
added somewhere else in the IR using Builder.Insert().
2020-02-24 19:38:47 +01:00
Peter Collingbourne 0414c56940 Revert "Rework go bindings so that validation works fine"
And add llvm-go back to the test dependencies.

No longer necessary now that llvm-go has been brought back.

This reverts commit e8f8873da5.
2020-02-24 09:20:08 -08:00
serge-sans-paille e8f8873da5 Rework go bindings so that validation works fine
Basically change the layout to please `go build` and remove references to
`llvm-go`.

Update llvm/test/Bindings/Go/ to use the system go compiler

Differential Revision: https://reviews.llvm.org/D74540
2020-02-13 14:13:03 +01:00
Adrian Prantl 63c4261720 Pass length of string in Go binding of CreateCompileUnit 2020-01-17 13:35:30 -08:00
Adrian Prantl 7b30370e5b Move the sysroot attribute from DIModule to DICompileUnit
[this re-applies c0176916a4
 with the correct commit message and phabricator link]

This addresses point 1 of PR44213.
https://bugs.llvm.org/show_bug.cgi?id=44213

The DW_AT_LLVM_sysroot attribute is used for Clang module debug info,
to allow LLDB to import a Clang module from source. Currently it is
part of each DW_TAG_module, however, it is the same for all modules in
a compile unit. It is more efficient and less ambiguous to store it
once in the DW_TAG_compile_unit.

This should have no effect on DWARF consumers other than LLDB.

Differential Revision: https://reviews.llvm.org/D71732
2020-01-17 12:55:40 -08:00
Adrian Prantl c17aee67f1 Revert "Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot"
This reverts commit 12e479475a.

I accidentally landed this patch with the wrong commit message ...
2020-01-17 12:52:36 -08:00
Adrian Prantl 94dd096f35 Revert "Attempt to fix Go syntax error"
This reverts commit c0176916a4.
2020-01-17 12:52:25 -08:00
Adrian Prantl c0176916a4 Attempt to fix Go syntax error 2020-01-17 12:37:15 -08:00
Adrian Prantl 12e479475a Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot
This is a purely cosmetic change that is NFC in terms of the binary
output. I bugs me that I called the attribute DW_AT_LLVM_isysroot
since the "i" is an artifact of GCC command line option syntax
(-isysroot is in the category of -i options) and doesn't carry any
useful information otherwise.

This attribute only appears in Clang module debug info.

Differential Revision: https://reviews.llvm.org/D71722
2020-01-17 09:36:48 -08:00