| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
'Error' : local variable is initialized but not referenced.
llvm-svn: 234982
|
|
|
|
| |
llvm-svn: 234981
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
for (int i = 0; i < in [a]; ++i) ..
After:
for (int i = 0; i < in[a]; ++i) ..
Also do some related cleanups.
llvm-svn: 234980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes LLVM not estimate branch probabilities when doing a
single bit bitmask tests.
The code that originally made me discover this is:
if ((a & 0x1) == 0x1) {
..
}
In this case we don't actually have any branch probability information
and should not assume to have any. LLVM transforms this into:
%and = and i32 %a, 1
%tobool = icmp eq i32 %and, 0
So, in this case, the result of a bitwise and is compared against 0,
but nevertheless, we should not assume to have probability
information.
CodeGen/ARM/2013-10-11-select-stalls.ll started failing because the
changed probabilities changed the results of
ARMBaseInstrInfo::isProfitableToIfCvt() and led to an Ifcvt of the
diamond in the test. AFAICT, the test was never meant to test this and
thus changing the test input slightly to not change the probabilities
seems like the best way to preserve the meaning of the test.
llvm-svn: 234979
|
|
|
|
|
|
|
|
| |
Adds proper codegen for 'firstprivate' clause in for directive. Initially codegen for 'firstprivate' clause was implemented for 'parallel' directive only.
Also this patch emits sync point only after initialization of firstprivate variables, not all private variables. This sync point is not required for privates, lastprivates etc., only for initialization of firstprivate variables.
Differential Revision: http://reviews.llvm.org/D8660
llvm-svn: 234978
|
|
|
|
|
|
|
| |
Hopefully this will fix the i686/msvc build failure described at:
http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/803
llvm-svn: 234977
|
|
|
|
| |
llvm-svn: 234976
|
|
|
|
|
|
|
|
| |
even if there are no references to them in the code.
This allows exceptions thrown from JIT'd code to be caught by the JIT itself.
llvm-svn: 234975
|
|
|
|
| |
llvm-svn: 234974
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Forgot to remove the include in r234970
llvm-svn: 234972
|
|
|
|
|
|
| |
fix build due to refactoring in DIL/MDL and raw_pwrite_stream
llvm-svn: 234971
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Now the callers of `PrintModulePass()` (etc.) that care about use-list
order in assembly pass in the flag.
llvm-svn: 234969
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 234965
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 234964
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 234963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Now the callers of `BitcodeWriterPass` decide whether or not to preserve
bitcode use-list order.
llvm-svn: 234959
|
|
|
|
| |
llvm-svn: 234958
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is a retry of r234944.
llvm-svn: 234955
|
|
|
|
| |
llvm-svn: 234954
|
|
|
|
| |
llvm-svn: 234953
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
make sure they are thread safe.
<rdar://problem/20263111>
llvm-svn: 234951
|
|
|
|
|
|
| |
The ELF object writer will take advantage of that in the next commit.
llvm-svn: 234950
|
|
|
|
|
|
| |
call clang with "-archx86_64" which doesn't work.
llvm-svn: 234949
|
|
|
|
|
|
|
| |
Since adding invokes of llvm.donothing to cleanups, we come here now,
and trivial EH cleanup usage from clang fails to compile.
llvm-svn: 234948
|
|
|
|
|
|
|
|
|
|
| |
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 reverts commit r234944 because it seems to have broken the buildbots.
llvm-svn: 234946
|
|
|
|
| |
llvm-svn: 234945
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is for consistency with what's used elsewhere in lld tree.
llvm-svn: 234943
|
|
|
|
|
|
|
| |
The frameescape intrinsic cannot be inlined, so I fixed the inliner in
r234937. This should address PR23216.
llvm-svn: 234942
|
|
|
|
| |
llvm-svn: 234941
|
|
|
|
| |
llvm-svn: 234940
|
|
|
|
|
|
|
|
| |
Patch by Eitan Adler.
Differential Revision: http://reviews.llvm.org/D8514
llvm-svn: 234939
|
|
|
|
| |
llvm-svn: 234938
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 234936
|
|
|
|
| |
llvm-svn: 234935
|
|
|
|
| |
llvm-svn: 234934
|
|
|
|
|
|
| |
Add unit test to verify recalculation
llvm-svn: 234933
|
|
|
|
| |
llvm-svn: 234932
|