Remove all the global bits to do with preserving use-list order by
moving the `cl::opt`s to the individual tools that want them. There's a
minor functionality change to `libLTO`, in that you can't send in
`-preserve-bc-uselistorder=false`, but making that bit settable (if it's
worth doing) should be through explicit LTO API.
As a drive-by fix, I removed some includes of `UseListOrder.h` that were
made unnecessary by recent commits.
llvm-svn: 234973
Follow up to r234962, start respecting `-emit-llvm-uselists even for
LLVM assembly. Note that the driver never passes this flag; this is
just a interface convenience/consistency for those using `-cc1`
directly. This required LLVM r234969 (and predecessors).
llvm-svn: 234970
Pull the `-preserve-ll-uselistorder` bit up through all the callers of
`Module::print()`. I converted callers of `operator<<` to
`Module::print()` where necessary to pull the bit through.
llvm-svn: 234968
For consistency, start pulling out `-preserve-ll-uselistorder`. I'll
drop the global state for both eventually. This pulls it up to
`Module::print()` (but not past there).
llvm-svn: 234966
Stop relying on `cl::opt` to pass along the driver's decision to
preserve use-lists. Create a new `-cc1` option called
`-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc).
Note that despite its generic name, it *doesn't* do the right thing when
-emit-llvm (LLVM assembly) yet. I'll hook that up soon.
This doesn't really change the behaviour of the driver. The default is
still to preserve use-lists for `clang -emit-llvm` and `clang
-save-temps`, and nothing else. But it stops relying on global state
(and also is a nicer interface for hackers using `clang -cc1`).
llvm-svn: 234962
Reverts the code changes from r234675 but keeps the test case.
We were already maintaining a DenseMap of globals with dynamic
initializers anyway.
Fixes the test case from PR23234.
llvm-svn: 234961
Now that `addBitcodeWriterPass()` requires an explicit bit to preserve
use-list order, send it in from `clang`. It looks like I'll be able to
push this up to the `-cc1` options.
llvm-svn: 234960
Change the callers of `WriteToBitcodeFile()` to pass `true` or
`shouldPreserveBitcodeUseListOrder()` explicitly. I left the callers
that want to send `false` alone.
I'll keep pushing the bit higher until hopefully I can delete the global
`cl::opt` entirely.
llvm-svn: 234957
Canonicalize access to whether to preserve use-list order in bitcode on
a `bool` stored in `ValueEnumerator`. Next step, expose this as a
`bool` through `WriteBitcodeToFile()`.
llvm-svn: 234956
Now we don't have to do 2 synchronized passes to compute offsets and then
write the file.
This also includes a fix for the corner case of seeking in /dev/null. It
is not an error, but on some systems (Linux) the returned offset is
always 0. An error is signaled by returning -1. This is checked by
the existing tests now that "clang -o /dev/null ..." seeks.
llvm-svn: 234952
HexagonEncodings.h contains a list of bitmasks. The file is used
only by HexagonRelocationHandler.cpp. The header is odd in the sense
that it uses struct Instruction but it doesn't define the data type.
This patch moves the struct definition to the header.
llvm-svn: 234947
This function is too long and complicated. Looks like new code was
added incrementaly without any refactoring. Maybe no one can describe
its exact semantics any more? It even contains copy-pastes inside it.
This patch is an (incomplete) attempt to simplify the function.
I tried to mechanically translate code to another form more intelligible.
I don't still understand the whole picture, but this patch shouldn't
change the linker's functionality.
llvm-svn: 234944
Inlining such intrinsics is very difficult, since you need to
simultaneously transform many calls to llvm.framerecover and potentially
duplicate the functions containing them. Normally this intrinsic isn't
added until EH preparation, which is part of the backend pass pipeline
after inlining. However, if it were to get fed through the inliner,
this change will ensure that it doesn't break the code.
llvm-svn: 234937
Summary:
There are a number of passes that could be sped up by using dominator tree DFS numbers to order or compare things across multiple bbs
(MemorySSA, MergedLoadStoreMotion, EarlyCSE, Sinking, GVN, NewGVN, for starters :P).
For example, GVN/CSE elimination can be done with a simple stack/etc (instead of full-on scoped hash table or repeated leader set walks)
if the DFS pair is stored next to leaders.
The dominator tree keeps them, and the DOM tree nodes expose them as public, but you have no guarantee they are up to date (and in fact,
if you split blocks or whatever during your pass, they definitely won't be)
This means passes either have to compute their own versions[1], or make 32 queries, or ....
Rather than try to hide this, i just made the API public, and make it do nothing if the numbers are already valid.
[1] Which we want as a non-recursive walk, which is not pretty, sadly,
because it cannot use the depth first iterators since you don't get called on the way back up. So you either have to do one walk with po_iterator
and one with df_iterator, or write your own non-recursive walk that looks identical to the one in updateDFSNumbers.
Reviewers: chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8946
llvm-svn: 234930
Change all the normally relevant output in `verify-uselistorder` from
using `dbgs()` to using `outs()` and `errs()`. Now you don't need
`-debug=uselistorder` to figure out what's going on (or at what stage
verification failed, or to get the paths of the left-behind temporary
files). This is a debugging tool, so I put the logging messages on
`outs()` and the error messages on `errs()`.
I also adjusted the output to be less ***loud***. Not sure why I was so
`*`-happy when I first wrote this.
llvm-svn: 234929
That helps to correctly write content of hash table if target and host
endianness are not the same. Right now that commit does not affect
any supported targets.
llvm-svn: 234928
Richard Trieu