| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the attributes from the base object.
Summary:
Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object.
A good example of improper behavior in the current implementation is section information associated with the GlobalObject. If a section was set for it, and GlobalOpt is creating/modifying a new object based on this one (often copying the original name), without this change new object will be placed in a default section, resulting in inappropriate properties of the new variable.
The argument here is that if customer specified a section for a variable, any changes to it that compiler does should not cause it to change that section allocation.
Moreover, any other properties worth representation in copyAttributesFrom() should also be propagated.
Reviewers: jmolloy, joker-eph, joker.eph
Subscribers: slarin, joker.eph, rafael, tobiasvk, llvm-commits
Differential Revision: http://reviews.llvm.org/D16074
llvm-svn: 258556
|
|
|
|
|
|
|
|
|
| |
emitted into a precompiled header to mirror the debug info emitted for
object files importing the PCH.
rdar://problem/24290667
llvm-svn: 258555
|
|
|
|
|
|
|
|
|
|
|
| |
This option matches the behaviour of ld64, that is it prevents globals
from being dead stripped in executables and dylibs.
Reviewed by Lang Hames
Differential Revision: http://reviews.llvm.org/D16026
llvm-svn: 258554
|
|
|
|
|
|
|
|
|
| |
\src\llvm-rw\include\llvm/Support/AlignOf.h(254) :
error C2872: 'detail' : ambiguous symbol
could be 'llvm::detail'
or 'llvm::support::detail'
llvm-svn: 258553
|
|
|
|
| |
llvm-svn: 258552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds a `-spp-no-statepoints` flag to PlaceSafepoints that
bypasses the code that wraps newly introduced polls and existing calls
in gc.statepoint. With `-spp-no-statepoints` enabled, PlaceSafepoints
effectively becomes a safpeoint **poll** insertion pass.
The eventual goal is to "constant fold" this option, along with
`-rs4gc-use-deopt-bundles` to `true`, once clients using gc.statepoint
are okay doing so.
Reviewers: pgavlin, reames, JosephTremoulet
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16439
llvm-svn: 258551
|
|
|
|
| |
llvm-svn: 258550
|
|
|
|
|
|
|
|
|
| |
This is a rather unhelpful warning indicating that the ternary operator return
types are mismatched, returning an integer and an enumeral type. Since the
integeral type is shorter to type, cast the enumeral type to `int`. Silences
the -Wextra warning from GCC.
llvm-svn: 258548
|
|
|
|
|
|
|
| |
We were unnecessarily stripping the const qualifier on the temporary variable.
Restore the constness to avoid the warning. NFC.
llvm-svn: 258547
|
|
|
|
|
|
|
|
| |
Address a couple of instances of -Wreturn-type warning from GCC. The switches
are covered, add an llvm_unreachable to the end of the functions to silence the
warning. NFC.
llvm-svn: 258546
|
|
|
|
|
|
|
|
|
|
|
| |
This test requires llvm-symbolizer to be able to convert a stack
address into a function name. It is only able to do this if the
DIA SDK was found at cmake time. Add a lit feature for this,
and let the test depend on it.
See also discussion in D15363.
llvm-svn: 258545
|
|
|
|
|
|
|
|
| |
Make the variable a member of the writer trait object owned
now by the writer. Also use a different generator interface
to pass the infoObject from the writer.
llvm-svn: 258544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extend support in the map clause SEMA for the expressions supported in the OpenMP 4.5 specification, namely member expressions.
Fix some bugs in the previous implementation of SEMA related with expressions that do not consist of single variable references.
Fix bug in parsing when the expression in the map clause do not start with an identifier: accept any expression in the map clause and check for validity in SEMA instead of just ignoring it.
Reviewers: hfinkel, kkwli0, arpith-jacob, carlo.bertolli, ABataev
Subscribers: cfe-commits, fraggamuffin, caomhin
Differential Revision: http://reviews.llvm.org/D16385
llvm-svn: 258543
|
|
|
|
|
|
|
|
|
|
| |
Also removes Darwin test case files from the expectedTimeout hard-coded
file list.
See:
http://reviews.llvm.org/D16423
llvm-svn: 258542
|
|
|
|
| |
llvm-svn: 258541
|
|
|
|
|
|
| |
Thanks to Justin Bogner for the suggestion.
llvm-svn: 258540
|
|
|
|
| |
llvm-svn: 258539
|
|
|
|
| |
llvm-svn: 258538
|
|
|
|
|
|
|
|
| |
The promote alloca pass didn't handle these intrinsics and crashed.
These intrinsics should accept any address space, but for now just
erase them to avoid breaking.
llvm-svn: 258537
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR26186.
Reviewers: grosser, jholewinski
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D16479
llvm-svn: 258536
|
|
|
|
|
|
|
|
|
|
| |
Using an array instead of ArrayRef would allow type inference, but
(short of using C99) one would still need to write
typedef uint16_t VT[];
LE.write(VT{0x1234, 0x5678});
llvm-svn: 258535
|
|
|
|
|
|
|
| |
Now that both callsites are identical, we can simplify the
prototype and make it easier to reason about the 2-CC case.
llvm-svn: 258534
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current behavior is incorrect, as the two CCs returned by
changeFPCCToAArch64CC, intended to be OR'ed, are instead used
in an AND ccmp chain.
Consider:
define i32 @t(float %a, float %b, float %c, float %d, i32 %e, i32 %f) {
%cc1 = fcmp one float %a, %b
%cc2 = fcmp olt float %c, %d
%and = and i1 %cc1, %cc2
%r = select i1 %and, i32 %e, i32 %f
ret i32 %r
}
Assuming (%a < %b) and (%c < %d); we used to do:
fcmp s0, s1 # nzcv <- 1000
orr w8, wzr, #0x1 # w8 <- 1
csel w9, w8, wzr, mi # w9 <- 1
csel w8, w8, w9, gt # w8 <- 1
fcmp s2, s3 # nzcv <- 1000
cset w9, mi # w9 <- 1
tst w8, w9 # (w8 & w9) == 1, so: nzcv <- 0000
csel w0, w0, w1, ne # w0 <- w0
We now do:
fcmp s2, s3 # nzcv <- 1000
fccmp s0, s1, #0, mi # mi, so: nzcv <- 1000
fccmp s0, s1, #8, le # !le, so: nzcv <- 1000
csel w0, w0, w1, pl # !pl, so: w0 <- w1
In other words, we transformed:
(c < d) && ((a < b) || (a > b))
into:
(c < d) && (a u>= b) && (a u<= b)
whereas, per De Morgan's, we wanted:
(c < d) && !((a u>= b) && (a u<= b))
Note that this problem doesn't occur in the test-suite.
changeFPCCToAArch64CC produces disjunct CCs; here, one -> mi/gt.
We can't represent that in the fccmp chain; it can't express
arbitrary OR sequences, as one comment explains:
In general we can create code for arbitrary "... (and (and A B) C)"
sequences. We can also implement some "or" expressions, because
"(or A B)" is equivalent to "not (and (not A) (not B))" and we can
implement some negation operations. [...] However there is no way
to negate the result of a partial sequence.
Instead, introduce changeFPCCToANDAArch64CC, which produces the
conjunct cond codes:
- (a one b)
== ((a olt b) || (a ogt b))
== ((a ord b) && (a une b))
- (a ueq b)
== ((a uno b) || (a oeq b))
== ((a ule b) && (a uge b))
Note that, at first, one might think that, when PushNegate is true,
we should use the disjunct CCs, in effect doing:
(a || b)
= !(!a && !(b))
= !(!a && !(b1 || b2)) <- changeFPCCToAArch64CC(b, b1, b2)
= !(!a && !b1 && !b2)
However, we can take advantage of the fact that the CC is already
negated, which lets us avoid special-casing PushNegate and doing
the simpler to reason about:
(a || b)
= !(!a && (!b))
= !(!a && (b1 && b2)) <- changeFPCCToANDAArch64CC(!b, b1, b2)
= !(!a && b1 && b2)
This makes both emitConditionalCompare cases behave identically,
and produces correct ccmp sequences for the 2-CC fcmps.
llvm-svn: 258533
|
|
|
|
|
|
|
|
|
|
|
|
| |
We verify that the op tree is eligible for CCMP emission in
isConjunctionDisjunctionTree, but it's also possible that
emitConjunctionDisjunctionTree fails later.
The initial check is useful, as it avoids building nodes
that will get discarded.
Still, make sure that inconsistencies don't happen with
an assert.
llvm-svn: 258532
|
|
|
|
| |
llvm-svn: 258531
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR25875. When the trailing comma in a macro argument list is
elided, we need to treat it similarly to the case where a variadic macro
misses one actual argument.
Reviewers: rnk, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15670
llvm-svn: 258530
|
|
|
|
| |
llvm-svn: 258529
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes one issue reported at https://llvm.org/bugs/show_bug.cgi?id=26184
There was missing cleanup code for the cached indirect lock pool. The change
will fix the reported case where it tries to initialize a lock after runtime
cleanup/reinitialization, but it is still possible that the user program runs
into another problem because most test programs have a call to __kmpc_set_lock
after cleanup/reinitialization without calling __kmpc_init_lock causing a crash/hang.
llvm-svn: 258528
|
|
|
|
|
|
| |
Patch by Tobias Edler Von Koch.
llvm-svn: 258527
|
|
|
|
| |
llvm-svn: 258526
|
|
|
|
| |
llvm-svn: 258525
|
|
|
|
|
|
|
| |
Patch by Vassil Vassilev!
Reviewed by Richard Smith.
llvm-svn: 258524
|
|
|
|
|
|
| |
These ones aren't directly emitted by mesa and inserted by a pass.
llvm-svn: 258523
|
|
|
|
| |
llvm-svn: 258522
|
|
|
|
|
|
|
| |
Use a worklist for the pre-order DFS instead of using recursion.
No functionality change is intended.
llvm-svn: 258521
|
|
|
|
|
|
|
|
|
|
|
| |
but to return object_error::parse_failed. Then made the code in llvm-nm
do for Mach-O files what is done in the darwin native tools which is to
print "bad string index" for bad string indexes. Updated the error message
in the llvm-objdump test, and added tests to show llvm-nm prints
"bad string index" and a test to print the actual bad string index value
which in this case is 0xfe000002 when printing the fields as raw hex.
llvm-svn: 258520
|
|
|
|
|
|
| |
rdar://problem/24290667
llvm-svn: 258519
|
|
|
|
| |
llvm-svn: 258518
|
|
|
|
|
|
| |
I missed this one in r258493.
llvm-svn: 258517
|
|
|
|
|
|
|
| |
These aren't supposed to be used outside of the backend,
so there aren't any users to worry about.
llvm-svn: 258516
|
|
|
|
| |
llvm-svn: 258515
|
|
|
|
|
|
| |
I don't think this was ever used.
llvm-svn: 258514
|
|
|
|
|
|
|
| |
Mesa doesn't use this, and this is pattern matched already
from fsub x, (ffloor x)
llvm-svn: 258513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename the version of __construct_node() that takes a hash as an
argument to __construct_node_hash(), and use perfect-forwarding when
Rvalue references are available. The primary motivation is to allow
other types through, since unordered_map's value_type is different from
__hash_table's value_type -- a follow-up will take advantage of this --
but the rename is general "goodness".
There should be no functionality change here (aside from enabling the
follow-up).
llvm-svn: 258511
|
|
|
|
| |
llvm-svn: 258509
|
|
|
|
|
|
|
|
|
| |
In InputSection.cpp it was possible to dereference null.
Had to change signature of relocateTlsOptimize to accept pointer instead of reference.
Differential revision: http://reviews.llvm.org/D16466
llvm-svn: 258508
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PCH files don't have a module signature and LLVM uses a nonzero DWO id as
an indicator for skeleton / module CUs. This change pins the DWO id for PCH
files to a known constant value.
The correct long-term solution here is to implement a module signature
that is an actual dterministic hash (at the moment module signatures are
just random nonzero numbers) and then enable this for PCH files as well.
<rdar://problem/24290667>
llvm-svn: 258507
|
|
|
|
|
|
|
|
|
|
|
|
| |
Volatile loads of type wider than a pointer get split by MSVC because
the base x86 ISA doesn't provide loads which are wider than pointer
width. LLVM assumes that it can emit an cmpxchg8b but this is
problematic if the memory is in a CONST memory segment.
Instead, provide behavior compatible with MSVC: split loads wider than a
pointer.
llvm-svn: 258506
|
|
|
|
|
|
| |
I'm not sure why it needs these braces, but they help locally.
llvm-svn: 258505
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16295
llvm-svn: 258504
|