| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This code doesn't care where the data it is processing comes from, so a
StringRef is probably the most natural interface.
llvm-svn: 215448
|
| |
|
|
|
|
|
|
|
| |
I initially thought I could implement COMDATs with aliases by just
internalizing GVs instead of dropping them. This is a counter
example: Internalizing one of the @a would make @b and @c point
to different variables.
llvm-svn: 215447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue caused the lldb prompt to not show up in certain cases, very
noticeable on Linux systems.
See details on this review:
http://reviews.llvm.org/D4863
And on this lldb-commits thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html
Change by Shawn Best.
(Much useful help and testing by the rest of the community, thanks all!)
llvm-svn: 215446
|
| |
|
|
|
|
| |
failing since r215176.
llvm-svn: 215445
|
| |
|
|
|
|
| |
This augments r214722, r214723 and r214507.
llvm-svn: 215444
|
| |
|
|
| |
llvm-svn: 215443
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
int
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa(const
typename aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaa);
After:
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
const typename aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaa);
llvm-svn: 215442
|
| |
|
|
| |
llvm-svn: 215441
|
| |
|
|
| |
llvm-svn: 215440
|
| |
|
|
|
|
| |
It's just too noisy and the warning isn't very helpful in those cases.
llvm-svn: 215439
|
| |
|
|
|
|
|
|
| |
tests.
Will become useful soon.
llvm-svn: 215438
|
| |
|
|
| |
llvm-svn: 215437
|
| |
|
|
|
|
| |
warnings
llvm-svn: 215436
|
| |
|
|
| |
llvm-svn: 215435
|
| |
|
|
| |
llvm-svn: 215434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the gcc docs, -include uses the current working directory
for the lookup instead of the main source file.
This patch gets rid of NormalizeIncludePath (which relied on an
implementation detail of FileManager / FileEntry for the include path
logic to work), and instead hands the correct lookup information down to
LookupFile.
This will allow us to change the FileEntry's behavior regarding its Name
caching.
llvm-svn: 215433
|
| |
|
|
|
|
|
|
| |
was created for rather than the TargetMachine since we only
needed the TM for the subtarget and we can get that from the
MF.
llvm-svn: 215432
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The combiner ignored DBG nodes when checking
the uses of a virtual register.
It combined a sequence like
%vreg1 = madd %vreg2, %vreg3,...
DBG_VALUE (%vreg1 ...)
%vreg4 = add %vreg1,...
to
%vreg4 = madd %vreg2, %vreg3
leaving behind a dangling DBG_VALUE with
a definition. This triggered an assertion
in the MachineTraceMetrics.cpp module.
llvm-svn: 215431
|
| |
|
|
|
|
| |
Fix by Tong Shen.
llvm-svn: 215424
|
| |
|
|
|
|
|
|
| |
DW_TAG_unspecified_parameter.
Fixes rdar://13690847
llvm-svn: 215423
|
| |
|
|
|
|
| |
This should cut all metadata community clang produces.
llvm-svn: 215422
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Type::dump() doesn't print a newline, which makes for a poor
experience in a debugger. This looks like it was an ommission
considering Value::dump() two lines above, so I've changed Type to add
a newline as well.
Of the two in-tree callers, one added a newline anyway, and I've
updated the other one to use Type::print instead.
llvm-svn: 215421
|
| |
|
|
|
|
| |
Patch by Gabriel Radanne <drupyog@zoho.com>
llvm-svn: 215420
|
| |
|
|
|
|
| |
Patch by Gabriel Radanne <drupyog@zoho.com>
llvm-svn: 215419
|
| |
|
|
|
|
|
|
|
| |
refactoring in 215384. This way it can unique multiple entries describing
the same piece even if they don't have the exact same location.
(The same piece may get merged in and be added from OpenRanges).
There ought to be a more elegant solution for this, though.
llvm-svn: 215418
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the use of the "%c" specifier for getting/setting times.
The semantics of this specifier differ between linux and Mac. I don't believe
the use of this specifier was important to the test.
The following tests now pass on linux.
test/input.output/iostream.format/ext.manip/get_time.pass.cpp
test/input.output/iostream.format/ext.manip/put_time.pass.cpp
llvm-svn: 215417
|
| |
|
|
|
|
| |
location so their diagnostics have somewhere to point.
llvm-svn: 215416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, avoid calling setTailCall(false) on musttail calls. The funciton
prototypes should be "congruent", so the shadow layout should be exactly
the same.
Second, avoid inserting instrumentation after a musttail call to
propagate the return value shadow. We don't need to propagate the
result of a tail call, it should already be in the right place.
Reviewed By: eugenis
Differential Revision: http://reviews.llvm.org/D4331
llvm-svn: 215415
|
| |
|
|
|
|
|
|
|
|
| |
This patch just adds the required return statements to slice_array::operator=
and mask_array::operator=.
Tests were added to check that the return value is the same as the object assigned
to.
llvm-svn: 215414
|
| |
|
|
|
|
|
|
|
|
|
| |
No functional change. To be used in future commits that need to look
for such instructions.
Reviewed By: rafael
Differential Revision: http://reviews.llvm.org/D4504
llvm-svn: 215413
|
| |
|
|
|
|
|
|
|
|
|
| |
variables had DIEs, due to a failure on Darwin."
I believe this was addressed by r215157 and r215227, so let's have
another go at the bots, etc.
This reverts commit r214880.
llvm-svn: 215412
|
| |
|
|
| |
llvm-svn: 215411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as long as possible.
** Context **
Each time the dominance information is modified, the dominator tree analysis
switches in a slow query mode. After a few queries without any modification on
the dominator tree, it performs an expensive update of its internal structure to
provide fast queries again.
** Problem **
Prior to this patch, the MachineSink pass was splitting the critical edges on
demand while relying heavy on the dominator tree information. In some cases,
this leads to pathological behavior where:
- We end up in the slow query mode right after splitting an edge.
- We update the dominance information.
- We break the dominance information again, thus ending up in the slow query
mode and so on.
** Proposed Solution **
To mitigate this effect, this patch postpones all the splitting of the edges at
the end of each iteration of the main loop.
The benefits are:
- The dominance information is valid for the life time of an iteration.
- This simplifies the code as we do not have to special treat instructions that
are sunk on critical edges. Indeed, the related block will be available
through the next iteration.
The downside is that when edges splitting is required, this incurs an additional
iteration of the main loop compared to the previous scheme.
** Performance **
Thanks to this patch, the motivating example compiles in 6+ minutes instead of
10+ minutes. No test case added as the motivating example as nothing special but
being huge!
I have measured only noise for both the compile time and the runtime on the llvm
test-suite + SPECs with Os and O3.
Note: The current implementation of MachineBasicBlock::SplitCriticalEdge also
uses the dominance information and therefore, hits this problem. A subsequent
patch will address that.
<rdar://problem/17894619>
llvm-svn: 215410
|
| |
|
|
| |
llvm-svn: 215409
|
| |
|
|
|
|
|
|
|
|
|
| |
it. Diagnose with recovery if it appears after a function parameter that was
obviously supposed to be a parameter pack. Otherwise, warn if it immediately
follows a function parameter pack, because the user most likely didn't intend
to write a parameter pack followed by a C-style varargs ellipsis.
This warning can be syntactically disabled by using ", ..." instead of "...".
llvm-svn: 215408
|
| |
|
|
|
|
| |
simplify common usage patterns.
llvm-svn: 215407
|
| |
|
|
| |
llvm-svn: 215406
|
| |
|
|
|
|
| |
This all appears to have been dead, unnecessary code.
llvm-svn: 215405
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
target hook.
This patch teaches the compiler that:
dX = VMOVDRR rY, rZ
is the same as:
dX = REG_SEQUENCE rY, ssub_0, rZ, ssub_1
<rdar://problem/12702965>
llvm-svn: 215404
|
| |
|
|
|
|
| |
as suggested by dblaikie in a comment on r215384.
llvm-svn: 215403
|
| |
|
|
| |
llvm-svn: 215402
|
| |
|
|
|
|
| |
Have the comments match the actual parameter names. Found via clang-tidy.
llvm-svn: 215401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
What follows bellow is a correctness proof of the transform using CVC3.
$ < t.cvc
A, B : BITVECTOR(32);
QUERY BVPLUS(32, A & B, A | B) = BVPLUS(32, A, B);
$ cvc3 < t.cvc
Valid.
llvm-svn: 215400
|
| |
|
|
|
|
|
| |
This saves us from having to copy a 64-bit 0 value into VGPRs for
BUFFER_* instruction which only have a 12-bit immediate offset.
llvm-svn: 215399
|
| |
|
|
| |
llvm-svn: 215398
|
| |
|
|
|
|
|
|
| |
There are no variable values like registers encoded in the low 32 bits of MUBUF
instructions, so it is relatively easy to check these bits, and it will
help prevent us from introducing encoding bugs.
llvm-svn: 215397
|
| |
|
|
|
|
|
|
| |
This bit was left uninitialized, which was causing some random failures
of piglit tests.
NOTE: This is a candidate for the 3.5 branch.
llvm-svn: 215396
|
| |
|
|
| |
llvm-svn: 215395
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch adds a new property: isRegSequence and the related target hooks:
TargetIntrInfo::getRegSequenceInputs and
TargetInstrInfo::getRegSequenceLikeInputs to specify that a target specific
instruction is a (kind of) REG_SEQUENCE.
<rdar://problem/12702965>
llvm-svn: 215394
|
| |
|
|
|
|
|
|
| |
anyway. If -ast-dump *is* also provided, then dump the AST declarations as well
as the lookup results. This is invaluable for cross-correlating the lookup
information with the declarations actually found.
llvm-svn: 215393
|