Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Sep 17, 2015
    • Devin Coughlin's avatar
      [analyzer] Add generateErrorNode() APIs to CheckerContext. · 440c44a9
      Devin Coughlin authored 
      The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all nodes (including the
error node), leading to an assertion failure (see
https://llvm.org/bugs/show_bug.cgi?id=24184).

This commit addresses the issue by adding two new APIs to CheckerContext to
explicitly create error nodes. Unless the client provides a custom tag, these
APIs tag the node with the checker's tag -- preventing it from being trimmed.
The generateErrorNode() method creates a sink error node, while
generateNonFatalErrorNode() creates an error node for a path that should
continue being explored.

The intent is that one of these two methods should be used whenever a checker
creates an error node.

This commit updates the checkers to use these APIs. These APIs
(unlike addTransition() and generateSink()) do not take an explicit Pred node.
This is because there are not any error nodes in the checkers that were created
with an explicit different than the default (the CheckerContext's Pred node).

It also changes generateSink() to require state and pred nodes (previously
these were optional) to reduce confusion.

Additionally, there were several cases where checkers did check whether a
generated node could be null; we now explicitly check for null in these places.

This commit also includes a test case written by Ying Yi as part of
http://reviews.llvm.org/D12163 (that patch originally addressed this issue but
was reverted because it introduced false positive regressions).

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247859 91177308-0d34-0410-b5e6-96231b3b80d8
      440c44a9
  3. Sep 15, 2015
  5. Sep 14, 2015
  7. Sep 11, 2015
  9. Sep 10, 2015
  11. Sep 09, 2015
  13. Sep 08, 2015
    • Richard Smith's avatar
      [modules] Write the options records to a separate subblock rather than writing · 02977dda
      Richard Smith authored 
      them directly to the control block. These are fairly large, and in a build with
lots of modules / chained PCH, we don't need to read most of them. No
functionality change intended.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247055 91177308-0d34-0410-b5e6-96231b3b80d8
      02977dda
    • Manuel Klimek's avatar
      Fix performance regression when running clang tools. · 90ea10e5
      Manuel Klimek authored 
      Brings tool start time for a large synthetic test case down from (on my
machine) 4 seconds to 0.5 seconds.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247018 91177308-0d34-0410-b5e6-96231b3b80d8
      90ea10e5
    • Manuel Klimek's avatar
      Fix documentation of numSelectorArgs. · 1b8011a8
      Manuel Klimek authored 
      Currently, the documentation for numSelectorArgs includes an incorrect
example. It shows a case where an argument of 1 will match a property
getter, but a getter will be matched only when N == 0.

This diff corrects the documentation and adds a test for numSelectorArgs(0).

Patch by Dave Lee.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246998 91177308-0d34-0410-b5e6-96231b3b80d8
      1b8011a8
    • John McCall's avatar
      Compute and preserve alignment more faithfully in IR-generation. · f4ddf94e
      John McCall authored 
      Introduce an Address type to bundle a pointer value with an
alignment.  Introduce APIs on CGBuilderTy to work with Address
values.  Change core APIs on CGF/CGM to traffic in Address where
appropriate.  Require alignments to be non-zero.  Update a ton
of code to compute and propagate alignment information.

As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.

The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned.  Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay.  I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.

Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.

We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment.  In particular,
field access now uses alignmentAtOffset instead of min.

Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs.  For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint.  That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.

ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments.  In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments.  That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.

I partially punted on applying this work to CGBuiltin.  Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246985 91177308-0d34-0410-b5e6-96231b3b80d8
      f4ddf94e
  15. Sep 05, 2015
  17. Sep 04, 2015