Commit Graph

612 Commits

Author SHA1 Message Date
Filipe Cabecinhas 0011c58444 Remove always-true comparison, NFC.
Summary:
Looking at r241279, I noticed that UpgradedIntrinsics only gets written
to in the following code:

    if (UpgradeIntrinsicFunction(&F, NewFn))
      UpgradedIntrinsics[&F] = NewFn;

Looking through UpgradeIntrinsicFunction, we always return false OR
NewFn will be set to a different function from our source.

This patch pulls the F != NewFn into UpgradeIntrinsicFunction as an
assert, and removes the check from callers of UpgradeIntrinsicFunction.

Reviewers: rafael, chandlerc

Subscribers: llvm-commits-list

Differential Revision: http://reviews.llvm.org/D10915

llvm-svn: 241369
2015-07-03 20:12:01 +00:00
Rafael Espindola d48e54c5ea Avoid a use after free.
llvm-svn: 241345
2015-07-03 12:20:34 +00:00
Rafael Espindola 4e7212177f Fix for PR23310: llvm-dis crashes when trying to upgrade an intrinsic.
When trying to upgrade @llvm.x86.sse2.psrl.dq while parsing a module,
BitcodeReader adds the function to its worklist twice, resulting in a
crash when accessing it the second time.

This patch replaces the worklist vector by a map.

Patch by Philip Pfaffe.

llvm-svn: 241281
2015-07-02 16:22:40 +00:00
Rafael Espindola 86e3340f31 Rangify some loops.
Patch by Philip Pfaffe!

llvm-svn: 241279
2015-07-02 15:55:09 +00:00
Adrian Prantl ab1243fe6c Add a DIModule metadata node to the IR.
It is meant to be used to record modules @imported by the current
compile unit, so a debugger an import the same modules to replicate this
environment before dropping into the expression evaluator.

DIModule is a sibling to DINamespace and behaves quite similarly.
In addition to the name of the module it also records the module
configuration details that are necessary to uniquely identify the module.
This includes the configuration macros (e.g., -DNDEBUG), the include path
where the module.map file is to be found, and the isysroot.

The idea is that the backend will turn this into a DW_TAG_module.

http://reviews.llvm.org/D9614
rdar://problem/20965932

llvm-svn: 241017
2015-06-29 23:03:47 +00:00
Alexander Kornienko f00654e31b Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)
Apparently, the style needs to be agreed upon first.

llvm-svn: 240390
2015-06-23 09:49:53 +00:00
Rafael Espindola 1c863ca3ea Remove the IsStreamed member variable.
Having different code paths for streamed and regular bitcode reading was a
source of bugs in the past and this defines them away.

It has a small but noticeable impact on performance. I timed running
"opt -disable-output -disable-verify" on a ltoed clang. It goes from

14.752845231 seconds time elapsed   ( +-  0.16% )

to

15.012463721 seconds time elapsed   ( +-  0.11% )

Extracted from a patch by Karl Schimpf.

llvm-svn: 240305
2015-06-22 18:06:15 +00:00
Alexander Kornienko 70bc5f1398 Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137
2015-06-19 15:57:42 +00:00
David Majnemer 7fddeccb8b Move the personality function from LandingPadInst to Function
The personality routine currently lives in the LandingPadInst.

This isn't desirable because:
- All LandingPadInsts in the same function must have the same
  personality routine.  This means that each LandingPadInst beyond the
  first has an operand which produces no additional information.

- There is ongoing work to introduce EH IR constructs other than
  LandingPadInst.  Moving the personality routine off of any one
  particular Instruction and onto the parent function seems a lot better
  than have N different places a personality function can sneak onto an
  exceptional function.

Differential Revision: http://reviews.llvm.org/D10429

llvm-svn: 239940
2015-06-17 20:52:32 +00:00
Rafael Espindola 456baad24d Handle forward referenced function when streaming bitcode.
Without this the included unit test would assert in

  assert(BasicBlockFwdRefs.empty() && "Unresolved blockaddress fwd references");

llvm-svn: 239871
2015-06-17 01:15:47 +00:00
Rafael Espindola 728074b73c Handle MaterializeAll in getLazyBitcodeModuleImpl. NFC.
This just handles both cases in the same place.

Extracted from a patch by Karl Schimpf.

llvm-svn: 239870
2015-06-17 00:40:56 +00:00
Rafael Espindola 1aabf982bc Use std::unique_ptr to manage the DataStreamer in bitcode parsing.
We were already deleting it, this just makes it explicit.

llvm-svn: 239867
2015-06-16 23:29:49 +00:00
Rafael Espindola dcd1dca275 Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.
llvm-svn: 239858
2015-06-16 22:27:55 +00:00
Rafael Espindola c6afe0d4e9 Improve handling of end of file in the bitcode reader.
Before this patch the bitcode reader would read a module from a file
that contained in order:

* Any number of non MODULE_BLOCK sub blocks.
* One MODULE_BLOCK
* Any number of non MODULE_BLOCK sub blocks.
* 4 '\n' characters to handle OS X's ranlib.

Since we support lazy reading of modules, any information that is relevant
for the module has to be in the MODULE_BLOCK or before it. We don't gain
anything from checking what is after.

This patch then changes the reader to stop once the MODULE_BLOCK has been
successfully parsed.

This avoids the ugly special case for .bc files in an archive and makes it
easier to embed bitcode files.

llvm-svn: 239845
2015-06-16 20:03:39 +00:00
Peter Collingbourne 82437bf7a5 Protection against stack-based memory corruption errors using SafeStack
This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).

The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.

Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.

This patch is our implementation of the safe stack on top of LLVM. The
patches make the following changes:

- Add the safestack function attribute, similar to the ssp, sspstrong and
  sspreq attributes.

- Add the SafeStack instrumentation pass that applies the safe stack to all
  functions that have the safestack attribute. This pass moves all unsafe local
  variables to the unsafe stack with a separate stack pointer, whereas all
  safe variables remain on the regular stack that is managed by LLVM as usual.

- Invoke the pass as the last stage before code generation (at the same time
  the existing cookie-based stack protector pass is invoked).

- Add unit tests for the safe stack.

Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.

Differential Revision: http://reviews.llvm.org/D6094

llvm-svn: 239761
2015-06-15 21:07:11 +00:00
Rafael Espindola 64a27fb801 Don't indent inside a namespace. NFC.
llvm-svn: 239760
2015-06-15 21:04:27 +00:00
Rafael Espindola 6ace68554d Replace @ with the more common \. NFC.
llvm-svn: 239759
2015-06-15 21:02:49 +00:00
Rafael Espindola cbdcb50554 Don't repeat names in comments and start functions with a lower case letter.
llvm-svn: 239756
2015-06-15 20:55:37 +00:00
Rafael Espindola 4223a1f811 Cleanup the constructor of BitcodeReader. NFC.
Use the same argument names as the members.
Use default member initializes.

Extracted from a patch by Karl Schimpf.

llvm-svn: 239749
2015-06-15 20:08:17 +00:00
Yaron Keren ef5e7addb3 Rangify two for loops in BitcodeReader.cpp.
llvm-svn: 239627
2015-06-12 18:13:20 +00:00
Filipe Cabecinhas a911af0e8c Use early return idiom. NFC
llvm-svn: 239228
2015-06-06 20:44:53 +00:00
Filipe Cabecinhas da86b6d409 [BitcodeReader] Diagnose type mismatches with aliases
Bug found with AFL fuzz.

llvm-svn: 238895
2015-06-03 01:30:13 +00:00
Filipe Cabecinhas 8e42190d20 [BitcodeReader] Check vector size before trying to create a VectorType
Bug found with AFL fuzz

llvm-svn: 238891
2015-06-03 00:05:30 +00:00
Filipe Cabecinhas 14e686774d [BitcodeReader] Change an assert to a call to a call to Error()
It's reachable from user input.

Bug found with AFL fuzz.

llvm-svn: 238633
2015-05-30 00:17:20 +00:00
Benjamin Kramer f5e2fc474d Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.


Call sites were found with the ASTMatcher + some semi-automated cleanup.

memberCallExpr(
    argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
    on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
    hasArgument(0, bindTemporaryExpr(
                       hasType(recordDecl(hasNonTrivialDestructor())),
                       has(constructExpr()))),
    unless(isInTemplateInstantiation()))

No functional change intended.

llvm-svn: 238602
2015-05-29 19:43:39 +00:00