| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 187895
|
| |
|
|
| |
llvm-svn: 187887
|
| |
|
|
|
|
| |
For now, builders in bb.pgr.jp are using it.
llvm-svn: 187886
|
| |
|
|
|
|
| |
with lowering logic and a test.
llvm-svn: 187884
|
| |
|
|
|
|
|
|
|
| |
This follows the same lines as the integer code. In the end it seemed
easier to have a second 4-bit mask in TSFlags to specify the compare-like
CC values. That eats one more TSFlags bit than adding a CCHasUnordered
would have done, but it feels more concise.
llvm-svn: 187883
|
| |
|
|
|
|
| |
These instructions can also be used as comparisons with zero.
llvm-svn: 187882
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thread one half of the select.
This is a common pattern coming out of simplifycfg generating gross code.
a: ; preds = %entry
%sel = select i1 %cmp1, double %add, double 0.000000e+00
br label %b
b:
%cond5 = phi double [ %sel, %a ], [ %sub, %entry ]
%cmp6 = fcmp oeq double %cond5, 0.000000e+00
br i1 %cmp6, label %if.then, label %if.end
becomes
a:
br i1 %cmp1, label %b, label %if.then
b:
%cond5 = phi double [ %sub, %entry ], [ %add, %a ]
%cmp6 = fcmp oeq double %cond5, 0.000000e+00
br i1 %cmp6, label %if.then, label %if.end
Skipping block b completely if possible.
llvm-svn: 187880
|
| |
|
|
|
|
|
|
|
|
| |
r187874 seems to have been missed by the build bot infrastructure, and
the subsequent commits to compiler-rt don't seem to be queuing up new
build requsets. Hopefully this will.
As it happens, having the space here is the more common formatting. =]
llvm-svn: 187879
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using it to detect whether or not a terminal supports colors. This
replaces a particularly egregious hack that merely compared the TERM
environment variable to "dumb". That doesn't really translate to
a reasonable experience for users that have actually ensured their
terminal's capabilities are accurately reflected.
This makes testing a terminal for color support somewhat more expensive,
but it is called very rarely anyways. The important fast path when the
output is being piped somewhere is already in place.
The global lock may seem excessive, but the spec for calling into curses
is *terrible*. The whole library is terrible, and I spent quite a bit of
time looking for a better way of doing this before convincing myself
that this was the fundamentally correct way to behave. The damage of the
curses library is very narrowly confined, and we continue to use raw
escape codes for actually manipulating the colors which is a much sane
system than directly using curses here (IMO).
If this causes trouble for folks, please let me know. I've tested it on
Linux and will watch the bots carefully. I've also worked to account for
the variances of curses interfaces that I could finde documentation for,
but that may not have been sufficient.
llvm-svn: 187874
|
| |
|
|
| |
llvm-svn: 187872
|
| |
|
|
| |
llvm-svn: 187870
|
| |
|
|
|
|
|
| |
This value may be used uninitialized in SIInsertWaits::insertWait.
Found with MemorySanitizer.
llvm-svn: 187869
|
| |
|
|
|
|
|
|
|
|
| |
lld has a hashtable with StringRef keys; it needs to iterate over the keys in
*insertion* order. This is currently implemented as std::vector<StringRef> +
DenseMap<StringRef, T>. This will probably need a proper
DenseMapInfo<StringRef> if we don't want to lose memory/performance by
migrating to a different data structure.
llvm-svn: 187868
|
| |
|
|
| |
llvm-svn: 187867
|
| |
|
|
|
|
|
|
|
|
| |
for StringRef with a StringMap
The bug is that the empty key compares equal to the tombstone key.
Also added an assertion to DenseMap to catch similar bugs in future.
llvm-svn: 187866
|
| |
|
|
|
|
|
|
|
|
|
| |
ret-true-on-succ.
As of this revision, all functions of LTOCodeGenerator are consistent in
ret-true-on-succ.
Tested on multiple OSes.
llvm-svn: 187864
|
| |
|
|
| |
llvm-svn: 187863
|
| |
|
|
| |
llvm-svn: 187862
|
| |
|
|
| |
llvm-svn: 187861
|
| |
|
|
| |
llvm-svn: 187860
|
| |
|
|
| |
llvm-svn: 187859
|
| |
|
|
| |
llvm-svn: 187858
|
| |
|
|
| |
llvm-svn: 187857
|
| |
|
|
| |
llvm-svn: 187856
|
| |
|
|
| |
llvm-svn: 187855
|
| |
|
|
|
|
|
| |
- Since we only have a few of these, use the cumbersome method of getting the
exception object from 'sys' to retain the current pre-2.6 compatibility.
llvm-svn: 187854
|
| |
|
|
| |
llvm-svn: 187853
|
| |
|
|
| |
llvm-svn: 187852
|
| |
|
|
| |
llvm-svn: 187851
|
| |
|
|
| |
llvm-svn: 187850
|
| |
|
|
| |
llvm-svn: 187849
|
| |
|
|
|
|
| |
effectively.
llvm-svn: 187848
|
| |
|
|
| |
llvm-svn: 187847
|
| |
|
|
|
|
|
|
|
|
| |
This fixes a bug from r187826.
Reviewers: hans
Differential Revision: http://llvm-reviews.chandlerc.com/D1304
llvm-svn: 187846
|
| |
|
|
|
|
|
| |
One use needs to copy the alloca into a std::string, and the other use
is before calling CreateProcess, which is very heavyweight anyway.
llvm-svn: 187845
|
| |
|
|
|
|
|
| |
Use it when we're looking for a string in particular. Update comments
as well.
llvm-svn: 187844
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 187843
|
| |
|
|
|
|
|
| |
columnWidth), and partially disable tests on MACOSX (which handles some
characters differently).
llvm-svn: 187842
|
| |
|
|
|
|
|
|
|
|
| |
Previously this check was guarded by MSVC, which doesn't distinguish
between the compiler and the headers/library. This enables clang to
compile more of LLVM on Windows with Microsoft headers.
Remove some unused macros while I'm here: error_t and LTDL stuff.
llvm-svn: 187839
|
| |
|
|
| |
llvm-svn: 187838
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generic UTF8-capable terminal.
Summary:
This is a second attempt to get this right. After reading the Unicode
Standard I came up with the code that uses definitions of "printable" and
"column width" more suitable for terminal output (i.e. fixed-width fonts and
special treatment of many control characters).
The implementation here can probably be used for Windows and MacOS if someone
can test it properly.
The patch addresses PR14910.
Reviewers: jordan_rose, gribozavr
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1253
llvm-svn: 187837
|
| |
|
|
|
|
| |
This should reduce some build bot warnings (D9025: "overriding '/GR' with '/GR-'").
llvm-svn: 187836
|
| |
|
|
| |
llvm-svn: 187834
|
| |
|
|
| |
llvm-svn: 187832
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the VSrc_* register classes contain both VGPRs and SGPRs, copies
that used be emitted by isel like this:
SGPR = COPY VGPR
Will now be emitted like this:
VSrC = COPY VGPR
This patch also adds a pass that tries to identify and fix situations where
a VGPR to SGPR copy may occur. Hopefully, these changes will make it
impossible for the compiler to generate illegal VGPR to SGPR copies.
llvm-svn: 187831
|
| |
|
|
|
|
| |
Also factor out the register class lookup to its own function.
llvm-svn: 187830
|
| |
|
|
|
|
| |
references, so get rid of the default-only switch statement. Fixes an MSVC warning.
llvm-svn: 187829
|
| |
|
|
|
|
| |
instructions defined in MipsInstrInfo.td as codegen-only instructions.
llvm-svn: 187828
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The globals being generated here were given the 'private' linkage type. However,
this caused them to end up in different sections with the wrong prefix. E.g.,
they would be in the __TEXT,__const section with an 'L' prefix instead of an 'l'
(lowercase ell) prefix.
The problem is that the linker will eat a literal label with 'L'. If a weak
symbol is then placed into the __TEXT,__const section near that literal, then it
cannot distinguish between the literal and the weak symbol.
Part of the problems here was introduced because the address sanitizer converted
some C strings into constant initializers with trailing nuls. (Thus putting them
in the __const section with the wrong prefix.) The others were variables that
the address sanitizer created but simply had the wrong linkage type.
llvm-svn: 187827
|
| |
|
|
|
|
|
|
|
|
| |
LLVM's coding standards recommend raw_ostream and MemoryBuffer for
reading and writing text.
This has the side effect of allowing clang to compile more of Support
and TableGen in the Microsoft C++ ABI.
llvm-svn: 187826
|