| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
The logic for expanding atomics that aren't natively supported in
terms of cmpxchg loops is much simpler to express at the IR level. It
also allows the normal optimisations and CodeGen improvements to help
out with atomics, instead of using a limited set of possible
instructions..
rdar://problem/13496295
llvm-svn: 212119
|
| |
|
|
|
|
| |
Fixes PR20169
llvm-svn: 212116
|
| |
|
|
|
|
| |
Fixes PR20167
llvm-svn: 212115
|
| |
|
|
|
|
|
|
|
| |
For now I only updated the _alt variants. The main variants are used by
codegen and that will need a bit more work to trigger.
<rdar://problem/17492620>
llvm-svn: 212114
|
| |
|
|
|
|
|
|
|
| |
Adding a writemask variant would require a third asm string to be passed to
the template. Generate the AsmString in the template instead.
No change in X86.td.expanded.
llvm-svn: 212113
|
| |
|
|
|
|
|
|
| |
This reverts commit r212088, which is causing a number of spec
failures. Will provide reduced test cases shortly.
PR20057
llvm-svn: 212109
|
| |
|
|
|
|
|
|
|
| |
to select the slice out of a Mach-O universal file. This also includes
support for -arch all, selecting the host architecture by default from
a universal file and checking if -arch is used with a standard Mach-O
it matches that architecture.
llvm-svn: 212108
|
| |
|
|
|
|
| |
Spotted by Amara Emerson.
llvm-svn: 212106
|
| |
|
|
| |
llvm-svn: 212105
|
| |
|
|
|
|
|
|
|
| |
There were transforms whose *intent* was to downgrade the linkage of
external objects to have internal linkage.
However, it fired on things with private linkage as well.
llvm-svn: 212104
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 212103
|
| |
|
|
| |
llvm-svn: 212102
|
| |
|
|
|
|
|
|
| |
This is a small targeted fix for pr20119. The code needs quiet a bit of
refactoring and I added some FIXMEs about it, but I want to get the testcase
passing first.
llvm-svn: 212101
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copies.
This patch extends the peephole optimization introduced in r190713 to produce
register-coalescer friendly copies when possible.
This extension taught the existing cross-bank copy optimization how to deal
with the instructions that generate cross-bank copies, i.e., insert_subreg,
extract_subreg, reg_sequence, and subreg_to_reg.
E.g.
b = insert_subreg e, A, sub0 <-- cross-bank copy
...
C = copy b.sub0 <-- cross-bank copy
Would produce the following code:
b = insert_subreg e, A, sub0 <-- cross-bank copy
...
C = copy A <-- same-bank copy
This patch also introduces a new helper class for that: ValueTracker.
This class implements the logic to look through the copy related instructions
and get the related source.
For now, the advanced rewriting is disabled by default as we are lacking the
semantic on target specific instructions to catch the motivating examples.
Related to <rdar://problem/12702965>.
llvm-svn: 212100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, no functionality change.
Before evicting a local variable, this heuristic tries to find another (set of)
local(s) that can be reassigned to a free color.
In some extreme cases (large basic blocks with tons of local variables), the
compilation time is dominated by the local interference checks that this
heuristic must perform, with no code gen gain.
E.g., the motivating example takes 4 minutes to compile with this heuristic, 12
seconds without.
Improving the situation will likely require to make drastic changes to the
register allocator and/or the interference check framework.
For now, provide this flag to better understand the impact of that heuristic.
<rdar://problem/17444599>
llvm-svn: 212099
|
| |
|
|
|
|
|
| |
This was kept around "for compatibility through 2.6" in 2009 and is not used or
tested.
llvm-svn: 212095
|
| |
|
|
|
|
|
|
|
|
|
| |
instructions within a function, lead to the function itself."
This reverts commit r212085.
This breaks the sanitizer bot... & I thought I'd tried pretty hard not
to do that. Guess I need to try harder.
llvm-svn: 212089
|
| |
|
|
|
|
| |
Fixes another test case under PR20057.
llvm-svn: 212088
|
| |
|
|
|
|
|
|
|
|
|
| |
ForceInterpreter=false shouldn't disable the interpreter completely because it
can still be necessary to interpret if the target doesn't support JIT.
No obvious way to test this in LLVM, but this matches what
LLVMCreateExecutionEngineForModule() does and fixes the clang-interpreter
example in the clang source tree which uses the ExecutionEngine.
llvm-svn: 212086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within a function, lead to the function itself.
Originally committed in r211723, reverted in r211724 due to failure
cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065),
and I now believe the invariant actually holds for some reasonable
amount of code (but I'll keep an eye on the buildbots and see what
happens... ).
Original commit message:
PR20038: DebugInfo: Inlined call sites where the caller has debug info
but the call itself has no debug location.
This situation does bad things when inlined, so I've fixed Clang not to
produce inlinable call sites without locations when the caller has debug
info (in the one case where I could find that this occurred). This
updates the PR20038 test case to be what clang now produces, and readds
the assertion that had to be removed due to this bug.
I've also beefed up the debug info verifier to help diagnose these
issues in the future, and I hope to add checks to the inliner to just
assert-fail if it encounters this situation. If, in the future, we
decide we have to cope with this situation, the right thing to do is
probably to just remove all the DebugLocs from the inlined instructions.
llvm-svn: 212085
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
seh_stackalloc 0 is not representable in Win64 SEH info, so emitting it
is a bug.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4334
Patch by Vadim Chugunov!
llvm-svn: 212081
|
| |
|
|
|
|
|
| |
An alias with an aliasee of a non-zero GEP is not trivially replacable
with it's aliasee.
llvm-svn: 212079
|
| |
|
|
| |
llvm-svn: 212078
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inlining functions with block addresses can cause many problem and requires a
rich infrastructure to support including escape analysis. At this point the
safest approach to address these problems is by blocking inlining from
happening.
Background:
There have been reports on Ruby segmentation faults triggered by inlining
functions with block addresses like
//Ruby code snippet
vm_exec_core() {
finish_insn_seq_0 = &&INSN_LABEL_finish;
INSN_LABEL_finish:
;
}
This kind of scenario can also happen when LLVM picks a subset of blocks for
inlining, which is the case with the actual code in the Ruby environment.
LLVM suppresses inlining for such functions when there is an indirect branch.
The attached patch does so even when there is no indirect branch. Note that
user code like above would not make much sense: using the global for jumping
across function boundaries would be illegal.
Why was there a segfault:
In the snipped above the block with the label is recognized as dead So it is
eliminated. Instead of a block address the cloner stores a constant (sic!) into
the global resulting in the segfault (when the global is used in a goto).
Why had it worked in the past then:
By luck. In older versions vm_exec_core was also inlined but the label address
used was the block label address in vm_exec_core. So the global jump ended up
in the original function rather than in the caller which accidentally happened
to work.
Test case ./tools/clang/test/CodeGen/indirect-goto.c will fail as a result
of this commit.
rdar://17245966
llvm-svn: 212077
|
| |
|
|
|
|
|
|
| |
In r212073 I missed a call of `use_begin()` that assumed the wrong
semantics. It's not clear to me at all what this code does without the
fix, so I'm not sure how to write a testcase.
llvm-svn: 212075
|
| |
|
|
|
|
|
|
| |
AArch64AddressTypePromotion was doing nothing because it was using the
old semantics of `Use` and `uses()`, when it really wanted to get at the
`users()`.
llvm-svn: 212073
|
| |
|
|
|
|
|
| |
Surprisingly, the i32* byval parameter is not transformed by
argpromotion.
llvm-svn: 212067
|
| |
|
|
|
|
|
|
|
|
|
| |
an invoke during inlining.
This both improves basic debug info quality, but also fixes a larger
hole whenever we inline a call/invoke without a location (debug info for
the entire inlining is lost and other badness that the debug info
emission code is currently working around but shouldn't have to).
llvm-svn: 212065
|
| |
|
|
| |
llvm-svn: 212063
|
| |
|
|
|
|
|
| |
MSVC was warning on a switch containing only default labels. In this
instance, it looks like it uncovered a real bug. :)
llvm-svn: 212062
|
| |
|
|
|
|
|
| |
This probably isn't necessary since msan started to unpoison the return
value shadow memory before all calls.
llvm-svn: 212061
|
| |
|
|
|
|
|
|
| |
This is a test for the fix in r211904.
Differential Revision: http://reviews.llvm.org/D4349
llvm-svn: 212059
|
| |
|
|
|
|
| |
variable into a helper function
llvm-svn: 212057
|
| |
|
|
| |
llvm-svn: 212056
|
| |
|
|
|
|
|
|
|
| |
Some versions of Android don't have futimes/futimens and this code wasn't
updated during the recent errc refactoring.
Patch by Luqman Aden!
llvm-svn: 212055
|
| |
|
|
|
|
|
|
| |
universal file. This also includes support for -arch all, selecting the host
architecture by default from a universal file and checking if -arch is used
with a standard Mach-O it matches that architecture.
llvm-svn: 212054
|
| |
|
|
| |
llvm-svn: 212052
|
| |
|
|
| |
llvm-svn: 212051
|
| |
|
|
|
|
|
|
|
|
|
| |
separate MDNode so they can be uniqued via folding set magic. To conserve
space, DIVariable nodes are still variable-length, with the last two
fields being optional.
No functional change.
http://reviews.llvm.org/D3526
llvm-svn: 212050
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for a new builtin instruction called
__builtin_ia32_rdpmc.
Builtin '__builtin_ia32_rdpmc' is defined as a 'GCC builtin'; on X86, it can
be used to read performance monitoring counters. It takes as input the index
of the performance counter to read, and returns the value of the specified
performance counter as a 64-bit number.
Calls to this new builtin will map to instruction RDPMC.
The index in input to the builtin call is moved to register %ECX. The result
of the builtin call is the value of the specified performance counter (RDPMC
would return that quantity in registers RDX:RAX).
This patch:
- Adds builtin int_x86_rdpmc as a GCCBuiltin;
- Adds a new x86 DAG node called 'RDPMC_DAG';
- Teaches how to lower this new builtin;
- Adds an ISel pattern to select instruction RDPMC;
- Fixes the definition of instruction RDPMC adding %RAX and %RDX as
implicit definitions, and adding %ECX as implicit use;
- Adds a LLVM test to verify that the new builtin is correctly selected.
llvm-svn: 212049
|
| |
|
|
| |
llvm-svn: 212048
|
| |
|
|
|
|
| |
PR20109
llvm-svn: 212045
|
| |
|
|
|
|
|
| |
The combine for mul x, pow2 +/- 1 is unchanged. Test cases for
both combines as well as mul x, pow2 have been added as well.
llvm-svn: 212044
|
| |
|
|
|
|
| |
I want to check them in lld.
llvm-svn: 212043
|
| |
|
|
|
|
|
|
| |
This fixes LNT SingleSource/UnitTests/Threads with -mthumb.
Differential Revision: http://reviews.llvm.org/D4324
llvm-svn: 212029
|
| |
|
|
| |
llvm-svn: 212021
|
| |
|
|
| |
llvm-svn: 212020
|
| |
|
|
| |
llvm-svn: 212019
|
| |
|
|
|
|
| |
Fix a comment typo `DbgLocLImport` instead of `DLLImport`.
llvm-svn: 212012
|
| |
|
|
|
|
|
| |
This just changes the constant value to the symbolic name corresponding to it.
NFC.
llvm-svn: 212011
|