History log of /llvm-project/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp (Results 251 – 275 of 1013)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 5fc5c7db 17-Feb-2020 Benjamin Kramer <benny.kra@googlemail.com>

Strength reduce vectors into arrays. NFCI.


Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1
# adcd0268 28-Jan-2020 Benjamin Kramer <benny.kra@googlemail.com>

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 ...


Revision tags: llvmorg-11-init
# 9c2eb220 26-Dec-2019 Teresa Johnson <tejohnson@google.com>

[ThinLTO] Summarize vcall_visibility metadata

Summary:
Second patch in series to support Safe Whole Program Devirtualization
Enablement, see RFC here:
http://lists.llvm.org/pipermail/llvm-dev/2019-D

[ThinLTO] Summarize vcall_visibility metadata

Summary:
Second patch in series to support Safe Whole Program Devirtualization
Enablement, see RFC here:
http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html

Summarize vcall_visibility metadata in ThinLTO global variable summary.

Depends on D71907.

Reviewers: pcc, evgeny777, steven_wu

Subscribers: mehdi_amini, Prazek, inglorion, hiraditya, dexonsmith, arphaman, ostannard, llvm-commits, cfe-commits, davidxl

Tags: #clang, #llvm

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

show more ...


# 7b30370e 14-Jan-2020 Adrian Prantl <aprantl@apple.com>

Move the sysroot attribute from DIModule to DICompileUnit

[this re-applies c0176916a4824812d25a5a22c4ff7c95857b0cd6
with the correct commit message and phabricator link]

This addresses point 1 of

Move the sysroot attribute from DIModule to DICompileUnit

[this re-applies c0176916a4824812d25a5a22c4ff7c95857b0cd6
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

show more ...


# c17aee67 17-Jan-2020 Adrian Prantl <aprantl@apple.com>

Revert "Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot"

This reverts commit 12e479475a896f664fb721f98c2d6805185ac352.

I accidentally landed this patch with the wrong commit message ...


# 12e47947 14-Jan-2020 Adrian Prantl <aprantl@apple.com>

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" i

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

show more ...


# 10cadee5 15-Jan-2020 evgeny <eleviant@accesssoftek.com>

[ThinLTO] Always import constants

This patch imports constant variables even when they can't be internalized
(which results in promotion). This offers some extra constant folding
opportunities.

Dif

[ThinLTO] Always import constants

This patch imports constant variables even when they can't be internalized
(which results in promotion). This offers some extra constant folding
opportunities.

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

show more ...


# b350c666 31-Dec-2019 David Blaikie <dblaikie@gmail.com>

Revert "DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode serialization/deserialization"

Seeing some curious CFI failures internally - which makes little sense
to me, as I don't think anyone is

Revert "DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode serialization/deserialization"

Seeing some curious CFI failures internally - which makes little sense
to me, as I don't think anyone is using this flag (even us,
internally)... so sounds like a bug in my code somewhere (possibly a
latent one that propagating this flag exposed, not sure). Reverting
while I investigate.

This reverts commit c51b45e32ef7f35c11891f60871aa9c2c04cd991.

show more ...


# c51b45e3 28-Dec-2019 David Blaikie <dblaikie@gmail.com>

DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode serialization/deserialization

Follow-up to r346788 review feedback from Adrian Prantl.


# c8e0bb3b 12-Dec-2019 Teresa Johnson <tejohnson@google.com>

[LTO] Support for embedding bitcode section during LTO

Summary:
This adds support for embedding bitcode in a binary during LTO. The libLTO gains supports the `-lto-embed-bitcode` flag. The option al

[LTO] Support for embedding bitcode section during LTO

Summary:
This adds support for embedding bitcode in a binary during LTO. The libLTO gains supports the `-lto-embed-bitcode` flag. The option allows users of the LTO library to embed a bitcode section. For example, LLD can pass the option via `ld.lld -mllvm=-lto-embed-bitcode`.

This feature allows doing something comparable to `clang -c -fembed-bitcode`, but on the (LTO) linker level. Having bitcode alongside native code has many use-cases. To give an example, the MacOS linker can create a `-bitcode_bundle` section containing bitcode. Also, having this feature built into LLVM is an alternative to 3rd party tools such as [[ https://github.com/travitch/whole-program-llvm | wllvm ]] or [[ https://github.com/SRI-CSL/gllvm | gllvm ]]. As with these tools, this feature simplifies creating "whole-program" llvm bitcode files, but in contrast to wllvm/gllvm it does not rely on a specific llvm frontend/driver.

Patch by Josef Eisl <josef.eisl@oracle.com>

Reviewers: #llvm, #clang, rsmith, pcc, alexshap, tejohnson

Reviewed By: tejohnson

Subscribers: tejohnson, mehdi_amini, inglorion, hiraditya, aheejin, steven_wu, dexonsmith, dang, cfe-commits, llvm-commits, #llvm, #clang

Tags: #clang, #llvm

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

show more ...


Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# 6a1b5128 18-Nov-2019 Andrew Browne <browneee@google.com>

Fix error message missed in commit dde589389fcb8b5098f7a47f1b781b27d29a0cac.

Patch by Andrew Browne <browneee@google.com>

Reviewers: tejohnson, evgeny777

Reviewed By: tejohnson

Subscribers: arpha

Fix error message missed in commit dde589389fcb8b5098f7a47f1b781b27d29a0cac.

Patch by Andrew Browne <browneee@google.com>

Reviewers: tejohnson, evgeny777

Reviewed By: tejohnson

Subscribers: arphaman, hiraditya, llvm-commits

Tags: #llvm

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

show more ...


# e87d7166 06-Nov-2019 aqjune <aqjune@gmail.com>

[IR] Redefine Freeze instruction

Summary:
This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction.

ConstantExpr freeze is removed, as discussed in the pre

[IR] Redefine Freeze instruction

Summary:
This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction.

ConstantExpr freeze is removed, as discussed in the previous review.
FreezeOperator is not added because there's no ConstantExpr freeze.
`freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed.
InstVisitor has visitFreeze now because freeze is not unaryop anymore.

Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri

Reviewed By: craig.topper, lebedev.ri

Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits

Tags: #llvm

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

show more ...


# b11391bb 08-Nov-2019 Teresa Johnson <tejohnson@google.com>

ThinLTO : Import always_inline functions irrespective of the threshold

Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation

ThinLTO : Import always_inline functions irrespective of the threshold

Summary: A user can force a function to be inlined by specifying the always_inline attribute. Currently, thinlto implementation is not aware of always_inline functions and does not guarantee import of such functions, which in turn can prevent inlining of such functions.

Patch by Bharathi Seshadri <bseshadr@cisco.com>

Reviewers: tejohnson

Reviewed By: tejohnson

Subscribers: mehdi_amini, inglorion, hiraditya, steven_wu, dexonsmith, arphaman, llvm-commits

Tags: #llvm

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

show more ...


# dde58938 07-Nov-2019 evgeny <eleviant@accesssoftek.com>

[ThinLTO] Import readonly vars with refs

Patch allows importing declarations of functions and variables, referenced
by the initializer of some other readonly variable.
Differential revision: https:/

[ThinLTO] Import readonly vars with refs

Patch allows importing declarations of functions and variables, referenced
by the initializer of some other readonly variable.
Differential revision: https://reviews.llvm.org/D69561

show more ...


# 58acbce3 05-Nov-2019 aqjune <aqjune@gmail.com>

[IR] Add Freeze instruction

Summary:
- Define Instruction::Freeze, let it be UnaryOperator
- Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter
The format is `%x = freeze <ty>

[IR] Add Freeze instruction

Summary:
- Define Instruction::Freeze, let it be UnaryOperator
- Add support for freeze to LLLexer/LLParser/BitcodeReader/BitcodeWriter
The format is `%x = freeze <ty> %v`
- Add support for freeze instruction to llvm-c interface.
- Add m_Freeze in PatternMatch.
- Erase freeze when lowering IR to SelDag.

Reviewers: deadalnix, hfinkel, efriedma, lebedev.ri, nlopes, jdoerfert, regehr, filcab, delcypher, whitequark

Reviewed By: lebedev.ri, jdoerfert

Subscribers: jfb, kristof.beyls, hiraditya, lebedev.ri, steven_wu, dexonsmith, xbolva00, delcypher, spatel, regehr, trentxintong, vsk, filcab, nlopes, mehdi_amini, deadalnix, llvm-commits

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

show more ...


# 46d317fa 07-Oct-2019 Cameron McInally <cameron.mcinally@nyu.edu>

[Bitcode] Update naming of UNOP_NEG to UNOP_FNEG

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

llvm-svn: 373958


# 6d4ea22e 25-Sep-2019 Sanjay Patel <spatel@rotateright.com>

[IR] allow fast-math-flags on phi of FP values (2nd try)

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917 <https://reviews.llvm.org/D61917>

As discussed th

[IR] allow fast-math-flags on phi of FP values (2nd try)

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917 <https://reviews.llvm.org/D61917>

As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086

The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535

But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.

The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.

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

llvm-svn: 372878

show more ...


# 2cec4b58 25-Sep-2019 Sanjay Patel <spatel@rotateright.com>

Revert [IR] allow fast-math-flags on phi of FP values

This reverts r372866 (git commit dec03223a97af0e4dfcb23da55c0f7f8c9b62d00)

llvm-svn: 372868


# dec03223 25-Sep-2019 Sanjay Patel <spatel@rotateright.com>

[IR] allow fast-math-flags on phi of FP values

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917

As discussed there, we want to have fast-math-flags be a pr

[IR] allow fast-math-flags on phi of FP values

The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917

As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086

The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535

But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.

The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.

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

llvm-svn: 372866

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# dc5f805d 23-Aug-2019 Benjamin Kramer <benny.kra@googlemail.com>

Do a sweep of symbol internalization. NFC.

llvm-svn: 369803


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init
# c5e7f562 15-Jul-2019 Evgeniy Stepanov <eugeni.stepanov@gmail.com>

ARM MTE stack sanitizer.

Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software impl

ARM MTE stack sanitizer.

Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.

The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.

Reviewers: pcc, hctim, vitalybuka, ostannard

Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 366123

show more ...


# 06263672 11-Jul-2019 Stefan Stipanovic <sstipanovic@s-energize.com>

[Attributor] Deduce "nosync" function attribute.

Introduce and deduce "nosync" function attribute to indicate that a function
does not synchronize with another thread in a way that other thread migh

[Attributor] Deduce "nosync" function attribute.

Introduce and deduce "nosync" function attribute to indicate that a function
does not synchronize with another thread in a way that other thread might free memory.

Reviewers: jdoerfert, jfb, nhaehnle, arsenm

Subscribers: wdng, hfinkel, nhaenhle, mehdi_amini, steven_wu,
dexonsmith, arsenm, uenoku, hiraditya, jfb, llvm-commits

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

llvm-svn: 365830

show more ...


Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4
# 6a4c2e4f 09-Jul-2019 Bob Haarman <llvm@inglorion.net>

[ThinLTO] only emit used or referenced CFI records to index

Summary: We emit CFI_FUNCTION_DEFS and CFI_FUNCTION_DECLS to
distributed ThinLTO indices to implement indirect function call
checking. Th

[ThinLTO] only emit used or referenced CFI records to index

Summary: We emit CFI_FUNCTION_DEFS and CFI_FUNCTION_DECLS to
distributed ThinLTO indices to implement indirect function call
checking. This change causes us to only emit entries for functions
that are either defined or used by the module we're writing the index
for (instead of all functions in the combined index), which can make
the indices substantially smaller.

Fixes PR42378.

Reviewers: pcc, vitalybuka, eugenis

Subscribers: mehdi_amini, hiraditya, dexonsmith, arphaman, llvm-commits

Tags: #llvm

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

llvm-svn: 365537

show more ...


# b4b21d80 08-Jul-2019 Brian Homerding <homerdin@gmail.com>

Add, and infer, a nofree function attribute

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., fre

Add, and infer, a nofree function attribute

This patch adds a function attribute, nofree, to indicate that a function does
not, directly or indirectly, call a memory-deallocation function (e.g., free,
C++'s operator delete).

Reviewers: jdoerfert

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

llvm-svn: 365336

show more ...


# 3aef3528 05-Jul-2019 Eugene Leviant <eleviant@accesssoftek.com>

[ThinLTO] Attempt to recommit r365188 after alignment fix

llvm-svn: 365215


1...<<11121314151617181920>>...41