types. This is the LLVM counterpart and it adds options that map onto FP
exceptions and denormal build attributes allowing better fp math library
selections.
Differential Revision: https://reviews.llvm.org/D24070
llvm-svn: 280246
Before this lld was always creating common symbols itself. It worked,
but prevented them from being internalized when possible.
Now it preserves common symbols is the bitcode and they are internalized.
Fixes pr30184.
llvm-svn: 280242
clang-format.py previously only worked in vim compiled against python2.
This patch adds the necessary syntax changes to make this work with vim
linked against python3, which is now shipped by default for at least Ubuntu16 and Arch.
Differential Revision: https://reviews.llvm.org/D23319
Subscribers: cfe-commits
llvm-svn: 280240
We check that a sinking candidate is used by only one PHI node during our legality checks. However for instructions that are used by other sinking candidates our heuristic is less conservative. This can result in a candidate actually being illegal when we come to sink it because of how we sunk a predecessor. Do the used-by-only-one-PHI checks again during sinking to ensure we don't crash.
llvm-svn: 280228
-ffast-math to CC1, but it included a wrong llvm regression tests which was
removed in r280065. Although regression test noexceptionsfpmath.c makes sure
-fno-trapping-math ends up as a function attribute, this adds a test that
explicitly checks the driver output for -fno-trapping-math.
llvm-svn: 280227
Summary:
Simply replace usage of aliases to functions with aliasee.
This came up when bitcode linking to builtin library and
calls to aliases not being resolved.
Also made minor improvements to existing test.
Reviewers: tstellarAMD, alex-t, vpykhtin
Subscribers: arsenm, wdng, rampitec
Differential Revision: https://reviews.llvm.org/D24023
llvm-svn: 280221
These clang tests check diagnostics from the backend by giving it an unvectorizable loop. This loop is now vectorized :/
Make it really unvectorizable by making it unprofitable to ifconvert.
llvm-svn: 280220
We're sinking stores, which is a good thing, but in the process creating selects for the store address operand, which SROA/Mem2Reg can't look through, which caused serious regressions.
The real fix is in SROA, which I'll be looking into.
llvm-svn: 280219
A very important case is not handled here: multiple arcs to a single block with a PHI. Consider:
a:
%1 = icmp %b, 1
br %1, label %c, label %e
c:
%2 = icmp %b, 2
br %2, label %d, label %e
d:
br %e
e:
phi [0, %a], [1, %c], [2, %d]
FoldValueComparisonIntoPredecessors will refuse to fold this, as it doesn't know how to deal with two arcs to a common destination with different PHI values. The answer is obvious - just split all conflicting arcs.
llvm-svn: 280218
This was a real restriction in the original version of SinkIfThenCodeToEnd. Now it's been rewritten, the restriction can be lifted.
As part of this, we handle a very common and useful case where one of the incoming branches is actually conditional. Consider:
if (a)
x(1);
else if (b)
x(2);
This produces the following CFG:
[if]
/ \
[x(1)] [if]
| | \
| | \
| [x(2)] |
\ | /
[ end ]
[end] has two unconditional predecessor arcs and one conditional. The conditional refers to the implicit empty 'else' arc. This same pattern can also be caused by an empty default block in a switch.
We can't sink the call to x() down to end because no call to x() happens on the third incoming arc (assume that x() has sideeffects for the sake of argument; if something is safe to speculate we could indeed sink nevertheless but this cannot happen in the general case and causes many extra selects).
We are now able to detect this case and split off the unconditional arcs to a common successor:
[if]
/ \
[x(1)] [if]
| | \
| | \
| [x(2)] |
\ / |
[sink.split] |
\ /
[ end ]
Now we can sink the call to x() into %sink.split. This can cause significant code simplification in many testcases.
llvm-svn: 280217
r279460 rewrote this function to be able to handle more than two incoming edges and took pains to ensure this didn't regress anything.
This time we change the logic for determining if an instruction should be sunk. Previously we used a single pass greedy algorithm - sink instructions until one requires more than one PHI node or we run out of instructions to sink.
This had the problem that sinking instructions that had non-identical but trivially the same operands needed extra logic so we sunk them aggressively. For example:
%a = load i32* %b %d = load i32* %b
%c = gep i32* %a, i32 0 %e = gep i32* %d, i32 1
Sinking %c and %e would naively require two PHI merges as %a != %d. But the loads are obviously equivalent (and maybe can't be hoisted because there is no common predecessor).
This is why we implemented the fairly complex function areValuesTriviallySame(), to look through trivial differences like this. However it's just not clever enough.
Instead, throw areValuesTriviallySame away, use pointer equality to check equivalence of operands and switch to a two-stage algorithm.
In the "scan" stage, we look at every sinkable instruction in isolation from end of block to front. If it's sinkable, we keep track of all operands that required PHI merging.
In the "sink" stage, we iteratively sink the last non-terminator in the source blocks. But when calculating how many PHIs are actually required to be inserted (to work out if we should stop or not) we remove any values that have already been sunk from the set of PHI-merges required, which allows us to be more aggressive.
This turns an algorithm with potentially recursive lookahead (looking through GEPs, casts, loads and any other instruction potentially not CSE'd) to two linear scans.
llvm-svn: 280216
This was deliberately disabled during my rewrite of SinkIfThenToEnd to keep behaviour
at least vaguely consistent with the previous version and keep it as close to NFC as
I could.
There's no real reason not to merge sideeffect calls though, so let's do it! Small fixup
along the way to ensure we don't create indirect calls.
Should fix PR28964.
llvm-svn: 280215
Patch removes VersionScriptParser class and moves the members to ScriptParser
It opens road for implementation of VERSION linkerscript command.
Differential revision: https://reviews.llvm.org/D23774
llvm-svn: 280212
As stated in PR28843:
we should handle command lines with
-target1-rel -target1-abs
--demangle --no-demangle
Patch implements this for specified options.
There are probably other conflicting options can exist,
so fix is called "partial".
Differential revision: https://reviews.llvm.org/D23867
llvm-svn: 280211
This patch groups relative relocations in a single block
in combrelocs mode and adds DT_RELCOUNT or DT_RELACOUNT
tag to .dynamic section
Differential revision: https://reviews.llvm.org/D23661
llvm-svn: 280210
DiscardPolicy is enum replacing several boolean options.
This approach is not only consistent with what we use for
unresolveds (UnresolvedPolicy), but also should help to solve a problem
of options with opposing meanings, mentioned in PR28843
Differential revision: https://reviews.llvm.org/D23868
llvm-svn: 280209
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
This approach is not only consistent with UnresolvedPolicy,
but also should help to solve a problem
of options with opposing meanings, mentioned in PR28843
Differential revision: https://reviews.llvm.org/D23869
llvm-svn: 280206
Allows adding start and/or end symbols to special output sections,
like .eh_frame_hdr, which aren't lists of regular input sections.
Differential revision: https://reviews.llvm.org/D23716
llvm-svn: 280205
Summary:
e80f43fd78
greatly improved an API, but missed one more occurence of legacy usage.
This leads to:
if (extractor.GetHexBytes(&payload_bytes[0], payload_bytes.size(), '\xdd') != payload_bytes.size())
~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
/lldb/include/lldb/Utility/StringExtractor.h:151:5: note: 'GetHexBytes' declared here
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24064
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 280202
Simon Pilgrim